callstackincubator

Simlock is all you need for self-hosting your own device cloud (not only simulators). Star it on GitHub and release that hardware capacity you might have there for mobile devices and testing callstackincubator/simlock

Four days since we launched Simlock: 500+ stars, 1,000 npm downloads, 90+ issues, 70+ merged PRs. 0.5.0 is out: agents can rotate leased iOS simulators, and tunnel ports to emulators on other machines. Hit a bug or missing a feature? Open an issue: callstackincubator/simlock t.co

Simlock leases, serves and manages iOS and Android devices for AI coding agents. You can turn your macOS and linux boxes into self-hosted cloud of simulators, emulators, and physical devices, that guarantees agents not fighting over the same device, control max number of simulators running at the same time to not clog CPU/RAM, run slim simulators with fewer services turned on, and many more. We considered making it a paid but it makes more sense to just open it for everybody. If you have one or more spare Mac or Linux machines laying around, setup simlock and make it your private sim cloud for yourself or your team. It's free, MIT licensed on GitHub: callstackincubator/simlock Enjoy :)

simlock is at 200 stars after half a day, let's make it to 1,000 ⭐ hop on the self-hosted device cloud bandwagon callstackincubator/simlock t.co

Introducing Simlock: a free, open-source tool that turns your machine into a simulator cloud that manages itself, so every coding agent gets its own iOS or Android device, simulator or real phone. callstackincubator/simlock t.co

Speedrun, an open-source mobile E2E test runner that runs your Maestro flows up to 8x faster I've always been bothered by how slow mobile UI tests are. Most of a test run is spent waiting: fixed sleeps, polling, comparing screenshots to guess whether the app is done animating. Coming from a game dev background, where you fight for every millisecond of a frame, that felt like a solvable problem. So I spent the last while building my own runner from the ground up, and it turns out UI tests can be a lot faster. Speedrun is a black-box E2E test runner for Android and iOS. It's open source (Apache 2.0) and it runs Maestro's YAML flow format so if you already have Maestro tests, trying it is one word: maestro test flows/ # before speedrun test flows/ # after Numbers One user journey (sign in with a code, search a shop, fill a cart, set a PIN under a loading overlay, scroll a long list), written for each tool the way its tests are usually written. Median of 3 runs after a warm-up, start-up included: |Tool|Android emulator|iOS simulator| |:-|:-|:-| |Speedrun|20.4 s|27.2 s| |maestro-runner|65.9 s|49.6 s| |Appium|59.4 s|94.1 s| |XCUITest|-|81.2 s| |Maestro 2.11|126.5 s|113.1 s| On the native Settings app benchmark it's 8x faster than Maestro on Android and 2.8x on iOS. On a 19-flow React-Native test suite it passes all 19 on both platforms, and is 6.1x faster on Android and 2.6x on iOS. Android is where it shines most, which is nice for CI: Android runs on cheap Linux runners. Full disclosure: the main benchmark app is mine, built in React Native to be hard to test (endless animations, late popups, loading overlays, lists that load as you scroll). The flows, per-flow results and scripts to rerun everything are in the repo, and I'd love to see numbers on other apps. Why it's fast - It waits for the app, not the clock. A small on-device agent knows when the app has actually settled (accessibility events on Android, XCTest's idle state checked against the screen on iOS), so each step starts the moment the app is ready. No sleeps, no screenshot diffing. - Reading the screen is cheap. The agent reads the UI tree in about 10 ms on Android and talks to the host over a compact binary protocol. - Screens that never stop moving don't block it. Spinners, tickers and carousels are left out of the "is it done?" check. - Nothing to warm up. One native binary, no JVM. The iOS agent stays running between runs, so later runs start in about 0.2 s. It's also less flaky: it won't tap a popup that's still sliding in or a button under a loading overlay, and it scrolls an element out from under a sticky footer or the keyboard before tapping it. It works with AI agents too speedrun mcp exposes it as an MCP server (Claude Code, Cursor, etc.). Your agent can explore the app on its own: tap around, read each screen in a few lines (cheap on tokens, not a whole accessibility tree), figure out how things work, then save the steps that worked as a YAML flow you can drop into CI. claude mcp add speedrun -- ~/.speedrun/speedrun mcp ||Android emulator|iOS simulator| |:-|:-|:-| |Speedrun (speedrun session)|4.2 s, ~1,560 tokens|9.4 s, ~1,230 tokens| |agent-device 0.21|9.1 s, ~2,240 tokens|14.0 s, ~1,620 tokens| |Argent 0.31|11.7 s, ~3,630 tokens|12.2 s, ~2,650 tokens| Limitations (so you don't have to find them) - Android emulators and devices, iOS **simulators** only (no real iOS devices yet) - macOS (Apple silicon); the Linux x86_64 build is Android-only - Maestro's AI commands (`assertWithAI` and co.) aren't supported; the few other differences are documented - It's young (v0.1.10) and moving fast Try it Repo, docs and benchmark details: hubastard/speedrun If you have a Maestro suite, I'd really like to hear how it does on yours, especially where it breaks or is slower. Happy to answer questions about how it works. edit1: added maestro-runner to the benchmark. edit2: added ai agent benchmark.

Speedrun, an open-source mobile E2E test runner (Android/iOS) that runs your Maestro flows up to 8x faster I've always been bothered by how slow mobile UI tests are. Most of a test run is spent waiting: fixed sleeps, polling, comparing screenshots to guess whether the app is done animating. Coming from a game dev background, where you fight for every millisecond of a frame, that felt like a solvable problem. So I spent the last while building my own runner from the ground up, and it turns out UI tests can be a lot faster. Speedrun is a black-box E2E test runner for Android and iOS. It's open source (Apache 2.0) and it runs Maestro's YAML flow format so if you already have Maestro tests, trying it is one word: maestro test flows/ # before speedrun test flows/ # after Numbers One user journey (sign in with a code, search a shop, fill a cart, set a PIN under a loading overlay, scroll a long list), written for each tool the way its tests are usually written. Median of 3 runs after a warm-up, start-up included: |Tool|Android emulator|iOS simulator| |:-|:-|:-| |Speedrun|20.4 s|27.2 s| |maestro-runner|65.9 s|49.6 s| |Appium|59.4 s|94.1 s| |XCUITest|-|81.2 s| |Maestro 2.11|126.5 s|113.1 s| On the native Settings app benchmark it's 8x faster than Maestro on Android and 2.8x on iOS. On a 19-flow React-Native test suite it passes all 19 on both platforms, and is 6.1x faster on Android and 2.6x on iOS. Android is where it shines most, which is nice for CI: Android runs on cheap Linux runners. Full disclosure: the main benchmark app is mine, built in React Native to be hard to test (endless animations, late popups, loading overlays, lists that load as you scroll). The flows, per-flow results and scripts to rerun everything are in the repo, and I'd love to see numbers on other apps. Why it's fast - It waits for the app, not the clock. A small on-device agent knows when the app has actually settled (accessibility events on Android, XCTest's idle state checked against the screen on iOS), so each step starts the moment the app is ready. No sleeps, no screenshot diffing. - Reading the screen is cheap. The agent reads the UI tree in about 10 ms on Android and talks to the host over a compact binary protocol. - Screens that never stop moving don't block it. Spinners, tickers and carousels are left out of the "is it done?" check. - Nothing to warm up. One native binary, no JVM. The iOS agent stays running between runs, so later runs start in about 0.2 s. It's also less flaky: it won't tap a popup that's still sliding in or a button under a loading overlay, and it scrolls an element out from under a sticky footer or the keyboard before tapping it. It works with AI agents too speedrun mcp exposes it as an MCP server (Claude Code, Cursor, etc.). Your agent can explore the app on its own: tap around, read each screen in a few lines (cheap on tokens, not a whole accessibility tree), figure out how things work, then save the steps that worked as a YAML flow you can drop into CI. claude mcp add speedrun -- ~/.speedrun/speedrun mcp ||Android emulator|iOS simulator| |:-|:-|:-| |Speedrun (speedrun session)|4.2 s, ~1,560 tokens|9.4 s, ~1,230 tokens| |agent-device 0.21|9.1 s, ~2,240 tokens|14.0 s, ~1,620 tokens| |Argent 0.31|11.7 s, ~3,630 tokens|12.2 s, ~2,650 tokens| Limitations (so you don't have to find them) - Android emulators and devices, iOS **simulators** only (no real iOS devices yet) - macOS (Apple silicon); the Linux x86_64 build is Android-only - Maestro's AI commands (`assertWithAI` and co.) aren't supported; the few other differences are documented - It's young (v0.1.10) and moving fast Try it Repo, docs and benchmark details: hubastard/speedrun If you have a Maestro suite, I'd really like to hear how it does on yours, especially where it breaks or is slower. Happy to answer questions about how it works. edit1: added maestro-runner to the benchmark edit2: added ai agent benchmark

Fast-Forwarding Past the 9 A.M. Reminder, Bob Ross Paints Straight to the GPU, and a README That Confesses Its Own Bugs --- title: "Fast-Forwarding Past the 9 A.M. Reminder, Bob Ross Paints Straight to the GPU, and a README That Confesses Its Own Bugs" published: true cover_image: dev-to-uploads.s3.us-east-2.amazonaws.com description: "Explore Appduct from Callstack, which turns your running app into an MCP server for AI agents, and react-native-skia-webgpu-video for GPU video editing on Skia 3." tags: reactnative, javascript, mobile, expo canonical_url: thereactnativerewind.com --- You’re reading The React Native Rewind #63. --- Great Scott, Your App Has a Time Machine Doc Brown needed a DeLorean and 1.21 gigawatts to jump forward in time. Our QA agents just need to test a reminder that fires at 9 a.m., and right now they sit and wait for it like the rest of us. Szymon Chmal and Callstack launched Appduct on October 20 to fix exactly that. What does it actually do? Appduct turns your running app into an MCP server (the protocol agents use to call outside tools). You register functions like advance_time, seed_cart or set_feature_flag, and the agent calls them instead of tapping through six screens. The handlers run your app's own code, so a test starts on the screen it cares about rather than the login page. Call advance_time with 60 seconds, and the 9 a.m. reminder fires without anyone staring at a clock. import { useAppductTool } from "@appduct/react-native"; import { z } from "zod"; export function AppductTools() { useAppductTool({ name: "seed_cart", description: "Fill the cart with test items.", inputSchema: z.object({ items: z.number() }), handler: async ({ items }) => ({ added: items }), }); return null; } Mount that near the root, and any agent that speaks MCP can call it. The same tool works in Swift, Kotlin, Flutter and on the web. Release builds leave it out unless you opt in. How does the agent know the app is ready? Instead of sleep(3000) and a prayer, the app posts an event like checkout_completed, and the agent waits for it. The connection runs through a small daemon on your machine and an encrypted WebSocket, paired with a single-use link (or a QR code on a real device). For the taps that still need tapping, it pairs with Callstack's agent-device. Does it work in normal tests? A day later came @appduct/e2e, which wraps the e2e tests you already have. One call fills the cart, and the test runner's AI agent gets the same tools. The same test runs on web, iOS and Android. !Appduct e2e seed cart demo Where our tests are going, they don't need login screens. 👉 Appduct --- !Ancient Aliens ProGuard meme Happy Little Frames Bob Ross could turn a blank canvas into a mountain range in half an hour. React Native video editing usually takes longer, plus a native SDK and a lot of bridge code. Sebastien Hecart published the first beta of react-native-skia-webgpu-video on October 19. What is it? It plays, composes and exports video on top of React Native Skia 3 and William Candillon's React Native WebGPU (the GPU API that Skia 3 now draws through). Every video frame lands on a Skia canvas, so we can paint text, shapes and filters straight on top. Frames travel from the phone's decoder to the encoder on the GPU, without a detour through JavaScript. The trick is that one worklet (a small function that runs off the JS thread) draws both the live preview and the exported file. const drawFrame: FrameDrawer = (props) => { 'worklet'; const { canvas, frames, width, height } = props; const frame = frames.clip; if (frame) { drawVideoFrame(canvas, frame, { x: 0, y: 0, width, height }, { fit: 'contain' }); } // Draw your Skia text, shapes, or overlays here. }; await exportVideoComposition({ videoComposition: composition, drawFrame, outPath, width: 1280, height: 720, frameRate: 30, bitRate: 5_000_000, }); It picks up where the older Skia Video left off, rewritten from scratch for Skia 3. Is anyone using it yet? Giulio Amato has already moved his video editor off Media3 (Android's native media library) and onto it. Because the same code draws the preview and the export, what we see on the timeline is exactly what lands in the file. !Skia video editor demo What's the catch? It's a beta, tested on an iPhone 15 Pro and a Pixel 8a. HDR isn't qualified yet. It pins exact Skia and WebGPU versions and needs the New Architecture and a native rebuild. So Expo Go is out. The README lists its known bugs with refreshing honesty, which is more than most of our side projects manage. Beta 3 on October 22 already cut a 4K frame on iOS from 33 MB to 12 MB. There are no mistakes, just happy little dropped frames. 👉 react-native-skia-webgpu-video --- !Afraid to ask pod install meme 📦 Nitro V1 alpha Marc Rousavy (@mrousavy) has opened the doors on the first Nitro V1 alpha, so library authors can grab the alpha-nightly tag and start poking at the future. The same week, his fbjni PR made every call into Java and Kotlin 14% faster, which is a lot of speed for one merged pull request. 📦 Radon IDE 1.20 The iPhone Duo simulator now folds right inside your editor, and Radon warns you before you launch an app that iOS 27 is about to crash for skipping the UIScene lifecycle. 📝 Supporting iPhone Duo with Expo Apple's first foldable landed on Friday, and Expo's guide explains why insets.top is suddenly zero and your tab bar has moved into a rail on the side. 📦 React Native Windows 0.85 The legacy architecture has finally been shown the door, so it's New Architecture only from here, and you'll need Visual Studio 2026 to get in. 📦 React Native Firebase 27 CocoaPods is out and Swift Package Manager is in on iOS, and the ML package has been laid to rest now that Google has discontinued it. 📦 Unistyles 3.6 A new experimental Metro integration lets you ditch the Babel plugin, and plain views now re-render in half the time. 📦 Hot Updater 1.1 Over-the-air updates now reach brownfield apps too, and bumping your version number no longer locks you out of shipping a quick fix. 📦 React Native Bottom Tabs 1.5 Swift Package Manager support has arrived, along with a new prominent tab role for the one tab on iOS 27 that deserves to stand out from the crowd. 📦 create-react-native-library 0.64 Satyajit Sahoo (@satya164) has taken the C++ template out of experimental, so your next native module can be written in C++ without feeling like a science project. 📦 React Native Better PDF 1.1 Hand it three PDFs and it stitches them into one document with a single page count and search, which is exactly the trick react-native-pdf can't pull off. !Goodbye GIF --- Authored by Luke Farrell and edited by Fran Ríos. If you’re enjoying this newsletter, why not help us grow? Share it with your friends, family, and even that one coworker who always “forgets” to update dependencies. Use this link: thereactnativerewind.com.

89 PRs in 3 days 🔥 There's an extreme overhaul coming to on-device AI 👀 Keep an eye callstackincubator/ai

AI in Mobile Apps: What It Actually Changes for Businesses in 2026 AI in mobile apps helps a business most when it removes a specific, repeated piece of work: answering the same customer messages, taking orders, predicting busy hours, flagging bad data. It helps least when it's added because "every app has AI now." After ten years of building mobile apps for food delivery, healthcare, workforce tracking, education and community products, my rule is simple: understand the business use case first, then decide whether AI belongs in it at all. That's the short answer. The rest of this article is the long one, written for two kinds of readers: business owners deciding where to spend money, and developers who will have to build what gets decided. How big is AI in mobile apps right now? Big, and growing fast. A few numbers worth knowing: - Sensor Tower projects that time spent in generative AI apps will roughly double, from 17.2 billion hours in the first half of 2025 to 36 billion hours in the first half of 2026 (Sensor Tower, State of AI 2026). - More than 200,000 apps now mention AI in their store descriptions, and together they're on track for around 10 billion downloads in that same half year (same report). - Amazon reports that shoppers who use its Rufus assistant convert at close to twice the rate of shoppers who don't (same report). But here's the number I find more useful. When Lazyweb looked at 809 real apps in July 2026, only about one in nine (10.9%) actually had a visible AI assistant or chat screen (Lazyweb Research). So everyone is talking about AI, a lot of apps put "AI" in their listing, and far fewer ship an AI feature that does real work. That gap is both the opportunity and the trap. AI helps an app sell. It doesn't make people stay. The most honest data on this comes from RevenueCat, which processes subscription payments for a huge share of mobile apps. Their 2026 report found that AI-powered apps are better at turning trial users into paying customers: 8.5% conversion versus 5.6% for apps without AI (Dataconomy summary of RevenueCat's report). Then the same users leave faster. After a year, 21.1% of AI app subscribers were still paying, compared with 30.7% for non-AI apps (TechCrunch). The interesting part came in RevenueCat's follow-up study. The best AI apps retained users just as well as non-AI apps, and the difference seemed to come down to whether the app's use case naturally turned into a habit (RevenueCat). That matches what I see with clients. AI is the shiny thing that gets someone to try your app. Whether they keep using it depends on whether the app solves a problem they have every week. AI can't fake that part. Start with the business problem, not the model A lot of clients come to me asking for "AI in the app." When I ask what they want it to do, the answer is usually some version of "we're not sure, but competitors have it." That's not a reason to build anything. Before I suggest AI for any project, I go through four questions: 1. What repeated task is eating your team's time? Replying to the same questions, entering orders by hand, checking timesheets. 2. Where are customers waiting or dropping off? A slow reply on WhatsApp can lose an order. 3. What data do you already have? AI without your own data is mostly a generic chatbot. 4. What happens when the AI is wrong? If the answer is "someone gets the wrong medicine" or "a payment fails," you need a human checking it. And if a plain rule, a filter, a better form or a normal algorithm solves the problem, use that. Every call to a large language model costs money per message, forever. A rule costs nothing to run. There's no reason to burn tokens on something a few lines of logic can handle. This is the same thinking I use when scoping any project, which I wrote about in how much does an app cost in 2026. What AI changes, industry by industry These are the industries I've personally shipped apps in. For each one, I'll say where I think AI earns its cost and where it doesn't. Food delivery and restaurants I spent two years on DineHome, a multi-vendor food delivery platform in Norway, building the customer app, the rider app and a kiosk-mode POS app, along with native modules for kiosk hardening, ESC/POS thermal printing and background GPS. Most of the hard work there was plain engineering. A receipt has to print every time. A kiosk has to stay locked. No AI model makes those more reliable. Where AI does earn its place in food delivery is the guessing work. Today, machine learning sits behind demand forecasting, delivery time estimates, rider dispatch, fraud checks, search ranking, promotions and menu recommendations on the big platforms (Research and Markets). For a smaller restaurant business, the two that matter most are knowing when the rush is coming so the kitchen can prep, and giving customers a delivery time that's actually true. And there's a third one that's often skipped: taking the order in the first place. More on that below. Healthcare At ChopDawg I maintained Nightingale, a tablet app that staff used to log in, see their patients and connect with a backend algorithm that assigned nurses. That assignment logic was an algorithm, not AI, and honestly, that was the right choice. In healthcare you need decisions you can explain and repeat. Where AI is clearly winning in healthcare is the paperwork around care. A 2026 survey of 120 US health systems found AI note-taking at 68% adoption, and AI-drafted replies to patient messages grew 80% in a year. Of the systems that could measure their return, more than half reported at least 2x (Fierce Healthcare). That's the pattern I'd follow in any health app: let AI draft, let a human approve. Workforce and field-service apps For ClickTime, an Australian workforce and timesheet system, I was the only mobile developer on the employee and admin apps. The core work was real-time background GPS through a custom native bridge, plus blocking fake GPS apps. Fake-GPS blocking is a rule problem, and rules handle it well. Where I'd add AI if I were building it today is the second layer: spotting patterns that no single rule catches, like a timesheet that doesn't match the route someone actually drove, and flagging it for a manager to review. The AI doesn't decide anything. It just points a human at the records worth checking. Education apps I've worked on support and maintenance for Kalaam, a Quran vocabulary and recitation app with 100K+ installs. Education is one of the places AI fits naturally: feedback on pronunciation through speech recognition, review sessions built around the words a learner keeps forgetting, and faster drafts for support replies. But for content where accuracy really matters, and religious content is the clearest example, AI should help people practice, not generate the material they're learning. The content stays verified by humans. AI works around it. Community and chat apps On Paragon, a team and community app, I helped deliver the first version from scratch in six months, with encrypted chat, Agora voice and video calling and OneSignal notifications. Community apps have obvious AI use cases: catching spam and abuse, summarizing long threads for people who missed them, and smarter notifications. There's a catch, though. If you promise users that their chat is encrypted, sending their messages to a cloud AI model to summarize them breaks that promise. In a case like that, an on-device model is the only honest option. Banking and retail I haven't built banking apps, but the big players show where this is heading. Bank of America says 60% of its Erica assistant's interactions are now proactive, meaning the assistant reaches out first instead of waiting to be asked (AI2 Work). The lesson for smaller businesses is that AI which nudges at the right moment (a reminder, a reorder, a payment due) is usually worth more than a chat box that sits there waiting. What we're building: order management through WhatsApp and chat This is where my own thinking is right now. At Averolt, we're building a prototype that lets business owners automate how they manage orders, through WhatsApp or a chatbot on their website, with customers writing in normal, human language. A customer types something like "two chicken biryani, one without raita, deliver at 8" the way they'd text a person. The AI turns that into a structured order, the system checks it, and the owner sees it ready to confirm, instead of copying it by hand from a chat thread. It passes my own test from earlier: - It's a repeated task that takes real staff time every day. - It uses a channel customers already use, so nobody needs to install anything new. - Success is easy to measure: orders handled, mistakes, time saved. - There's a human in the loop before anything is final. That's the kind of AI feature I believe in. Not AI for the listing, AI for the boring work. On-device or cloud AI? For most businesses, both There's a lot of excitement about on-device AI, and the tools are genuinely good now. For React Native, React Native ExecuTorch from Software Mansion runs models on the phone, Callstack's React Native AI works with Apple's on-device models and Gemini Nano, and at WWDC 2026 Apple's Foundation Models gained image input on top of text (Callstack). But in my experience, an app that runs fully on-device and offline is a rare requirement for businesses. When a feature truly needs it, because of no connectivity, sensitive data, or server costs that would grow with every user, then stick with on-device and save the server bill. On-device models are also smaller and can only handle short inputs, so they suit focused tasks rather than open-ended chat (Infosys). Most of the time, the right setup is both: an offline layer on the client so the app feels instant and smooth, and cloud sync for backup and the heavier work. It's the same principle I use for data in general, which I covered in Firestore data modeling for offline-first React Native apps. AI is no different. Do the quick, private work on the phone, and send the rest to the cloud only when it adds something. A quick checklist before you add AI to your app - Name the exact task the AI will do, in one sentence. - Check if a rule or simple algorithm already solves it. - Make sure you have the data the feature needs. - Decide what a human must approve before it takes effect. - Estimate the per-use cost, not just the build cost. - Choose on-device, cloud or both based on privacy, connectivity and cost. - Measure whether it improves something real: orders, time saved, retention. FAQ Does every mobile app need AI in 2026? No. Only about one in nine apps had a visible AI assistant as of July 2026, and many successful apps have none. Add AI when it removes repeated work or improves a decision, not to match a competitor's listing. Which industries benefit most from AI in mobile apps? Industries with lots of repeated communication and prediction: food delivery and restaurants (orders, demand, delivery times), healthcare (documentation and patient messages), field service (anomaly checks), education (personalized practice) and retail and banking (proactive reminders). Will AI features help my app keep users? Not on their own. RevenueCat's 2026 data shows AI apps convert trials better but lose subscribers faster, unless the app solves a problem people have regularly. Retention comes from the use case, not from the AI. Is on-device AI better than cloud AI? Neither is better everywhere. On-device AI is private, fast and has no per-use server cost, but the models are smaller. Cloud AI is more capable but costs money per request. Most business apps work best with both. How much does it cost to add AI to an app? It depends on whether the feature runs on-device or calls a cloud model, how often it runs and how much testing it needs. The ongoing cost per use matters as much as the build cost. I break down what drives app costs in this article. Can AI handle customer orders through WhatsApp? Yes. AI can read an order written in normal language and turn it into a structured order for the business to confirm. Keeping a human confirmation step avoids costly mistakes while still saving most of the manual work. Want to figure out where AI fits in your business? If you're a founder or business owner who wants AI to do real work, not just appear in your app listing, there are two ways to work with me: - For a full product, web and mobile: my agency Averolt builds and rescues apps and systems end to end. - For React Native work: I take on senior React Native projects directly, from discovery to post-launch. Book a call. Either way, the first conversation starts with your business, not with AI. --- Sources - Sensor Tower: State of AI 2026 - Lazyweb Research: share of apps with an AI assistant - TechCrunch: AI apps struggle with long-term retention - RevenueCat: AI app retention study - Fierce Healthcare: health system AI adoption 2026 - Research and Markets: food delivery app market - Callstack: on-device AI after WWDC 2026 - Infosys: on-device AI for React Native Originally published on jahanzaibramzan.com.