September 2026 Summaries

AI-built apps undergo the same Apple App Store review process as hand-coded apps, with approval determined by compliance with App Review Guidelines rather than the tools used to create them. The main risks are incomplete or simulated functionality, exposed API keys, dependence on temporary development servers, inaccurate privacy disclosures, unnecessary permissions, unlicensed assets, and poorly implemented account deletion or in-app purchase flows. Apps that share user data with third-party AI services must clearly disclose that sharing and obtain explicit consent, while AI-generated outputs should be handled transparently and reliably when errors occur. Developers should test the exact release build on a clean device, verify all server-side behavior and purchases, provide functional reviewer credentials, ensure screenshots and metadata match the submitted version, and avoid hidden review-only paths. The guidance also notes that apps need meaningful functionality beyond generic templates or thin AI wrappers, while Expo’s build, submission, and update tools can support distribution but cannot guarantee policy compliance or replace testing of the signed iOS build.

Cross-platform mobile development enables teams to build iOS and Android applications from a shared codebase rather than maintaining separate Swift/Objective-C and Kotlin/Java projects, with adoption rising as React Native and Flutter accounted for 15% of new major app-store releases in 2024. Capacitor packages web applications in native shells, Flutter uses Dart and its own rendering engine, Kotlin Multiplatform primarily shares business logic while retaining native interfaces, .NET MAUI maps C# and XAML controls to native components, and React Native uses JavaScript or TypeScript to drive platform-native views. The best choice generally depends on existing team skills, desired interface fidelity, performance needs, platform API access, and the amount of code that should be shared. Cross-platform development can reduce staffing, release, and feature-parity costs, but it may introduce performance overhead and delays in accessing newly released native APIs, especially for web-view approaches. Native development remains preferable for platform-specific design, advanced 3D, AR, camera, and real-time processing workloads, or when maintaining separate apps is economically feasible. Major companies use Flutter, Kotlin Multiplatform, and React Native, while Expo provides a React Native-focused framework with routing, native modules, cloud build services, and update tooling.

App startup time varies by launch state and measurement endpoint, so cold, warm, and hot launches must be distinguished and first-frame metrics should not be confused with the time until a screen is genuinely usable. Android measures time to initial display and optionally time to full display, while Apple generally measures from icon tap to first frame; tools such as Firebase, Xcode Organizer, MetricKit, Macrobenchmark, Sentry, and Expo may use different start and stop points. Production monitoring should pair first-frame data with a product-specific “ready” or time-to-interactive marker set only after essential content and controls are available, while separately tracking crashes, hangs, failures, and timeouts that may otherwise disappear from latency percentiles. Meaningful release comparisons require release builds, segmentation by device, operating system, launch state, and entry path, plus percentile counts and trace-level investigation. Performance improvements should focus on work on the critical path, defer unnecessary initialization and data loading, reduce framework, native module, and JavaScript bundle costs where relevant, and remeasure both visual and usable startup after changes. Expo’s EAS Observe provides production startup metrics for supported React Native apps, but its definitions differ from platform-native metrics, reinforcing that teams must define their own usability budget and document exactly what their dashboards measure.

Production mobile-app bugs can be addressed while a store release is pending through expedited App Store review, pre-existing feature flags or remote configuration, and over-the-air (OTA) JavaScript updates, each with distinct limits. Expedited review can prioritize critical fixes but still requires approval and user installation, while kill switches can quickly disable risky features or correct server-provided data only when the shipped app already supports them. OTA systems such as Expo EAS Update can rapidly deliver JavaScript and asset fixes to compatible React Native or Expo builds, but cannot modify native code, permissions, SDK versions, or core app functionality, which still require a new binary and store review. Store policies permit limited interpreted-code updates for bug fixes but prohibit using them to introduce substantial new functionality. Safe OTA deployment depends on testing against a production-matched staging build, gradually rolling out updates while monitoring outcomes, planning rollback procedures, and embedding the eventual fix in the next native release.

App Store rejections occur when an app build or its metadata violates Apple’s review guidelines, with more than 40% of unresolved issues reportedly involving App Completeness problems such as crashes, broken links, placeholder content, inaccessible backend services, or unusable demo accounts. Common additional concerns include inaccurate store metadata, improper in-app purchase implementations, insufficient functionality, duplicate or copycat apps, noncompliant third-party login options, and privacy or account-deletion failures. Developers are advised to reproduce the reviewer’s exact path using a clean device and the supplied review credentials, distinguish binary or server defects from metadata-only errors, preserve the submitted build and logs during investigation, and provide concise resubmission notes explaining the correction and how to verify it. Preventive measures include maintaining realistic review accounts, testing empty states and authentication edge cases, ensuring privacy disclosures match all first- and third-party data collection, and reviewing purchase, deletion, and login flows end to end. Appeals are available when a reviewer has misunderstood compliant functionality, while repeated violations can delay review; tools such as Expo EAS can upload builds but cannot alter Apple’s approval criteria or fix a rejected binary without a new review submission.

Agentic CI combines Expo EAS Workflows with TesterArmy to adapt mobile app testing to each pull request rather than running an identical fixed test suite, aiming to give reviewers recordings and evidence that changed user-facing functionality works before merging. The approach uses AI agents to configure EAS build profiles for iOS Simulator apps and Android APKs, securely access TesterArmy credentials through EAS environment variables, build or reuse native artifacts through fingerprinting and repacking for JavaScript-only changes, upload builds, and run saved regression tests. For pull requests, TesterArmy analyzes the code diff and description, determines whether a platform-specific user-visible change requires testing, generates natural-language test steps, executes them in cloud simulators or emulators, and posts results and videos to GitHub. Failed exploratory tests are advisory by default but can be configured as required merge-blocking checks, while non-user-facing changes can be skipped with an explanation. The workflow can also connect coding agents such as Claude Code, Codex, or Cursor to testing instructions embedded in pull request descriptions, creating a loop in which agents write changes, EAS builds or repacks them, and testing agents validate them. TesterArmy cites Juno, an Expo-based health-app team, as an example of a high-volume adopter that reported substantially faster pull request throughput, and recommends beginning with its example repository and a verified saved test before enabling dynamic testing and build reuse.

Mobile app testing combines different test scopes—unit, component, integration, and end-to-end—with environments such as local test runners, simulators or emulators, and physical devices, which address different risks and should not be confused. Teams can use tools including Jest and React Native Testing Library for React Native logic and components, XCTest and Espresso for native platforms, and Appium, Detox, or Maestro for installed-app automation, while cloud services provide access to varied real devices. Effective testing starts from controlled data and accounts, verifies resulting state rather than only visible messages, runs final checks on release builds, and includes failures such as lost connectivity, denied permissions, backgrounding, expired sessions, upgrades, accessibility, and hardware-dependent behavior. Reliable release decisions require linking every result to a specific build and commit, preserving failure logs, documenting tested journeys and known gaps, and selecting device coverage based on user needs. Expo supports Jest-based testing, development builds, and EAS workflows that can connect builds to Maestro tests, though virtual devices cannot replace physical-device checks for real performance, sensors, and native integrations.

An agentic mobile-development workflow uses an AI coding agent to interpret build failures, test results, bug reports, or production signals, make narrowly scoped code changes, and repeatedly invoke predictable CI jobs until checks pass or a defined blocker is reached. Unlike conventional CI/CD pipelines, which execute fixed steps, the agent selects its next action based on outcomes while humans retain authority over approvals and releases. Effective implementations require reproducible triggers, branch-based changes, detailed and sanitized run records, structured test outputs, clear distinctions between untestable and failed platforms, limited credentials, retry budgets, and separate review of test expectation changes versus feature code. The approach is best suited to tasks requiring interpretation, such as linker errors, flaky UI tests, crash reports, and reproducible timeout bugs, rather than routine commands. Tools may include coding agents such as Claude Code or Codex, CI services, mobile test frameworks, simulator-control tools, and production-monitoring platforms; Expo’s EAS Workflows, MCP Server, approval jobs, and related services can provide build, test, log, and release infrastructure, but do not replace the reasoning agent or human release judgment.

Choosing a mobile development stack should be treated as a business decision based on time to launch on both platforms, release frequency, ongoing feature cost, and speed of production fixes rather than language preference alone. Native Swift and Kotlin offer maximum platform control, early API access, and advantages for demanding graphics, AR, camera, and performance-sensitive products, but usually require separate teams, codebases, releases, and maintenance efforts. Cross-platform alternatives reduce duplication in different ways: Flutter provides a highly controlled, consistent rendering engine for custom interfaces, Kotlin Multiplatform shares business logic while retaining native UI options, and React Native enables a shared JavaScript or TypeScript codebase using native platform components, including limited over-the-air updates for JavaScript and assets. Web wrappers such as Capacitor and Ionic can be the fastest and cheapest choice for existing web products and internal tools, although their web-view performance and interaction quality may be less suitable for consumer-facing apps. Hiring availability, existing team skills, platform-specific roadmap needs, and the growing but still imperfect role of AI coding tools all influence the tradeoff, while Expo can simplify React Native development, cloud builds, submissions, and staged updates. The recommended choice depends on organizational context, with native favoring platform-first or technically intensive apps, Flutter fitting custom visual systems, Kotlin Multiplatform serving Android-centered teams, React Native fitting web-skilled teams targeting both platforms, and web wrappers fitting budget-constrained or web-first use cases.

EAS Workflows and the early-access EAS Simulator enable an agentic development process in which coding agents investigate reported app bugs on cloud-hosted simulators, propose fixes, verify them, and open pull requests supported by evidence. In the example, a GitHub issue claiming that Settings crashes when scrolled triggers a workflow that sends the report to Claude Code, which uses Callstack’s agent-device CLI to install the app, observe that Settings crashes immediately, document the reproduction, identify and fix the cause, and validate the repaired app in a separate simulator session. The resulting pull request includes the diagnosis, code changes, before-and-after screenshots, replay links for both sessions, and passing test, lint, and type-check results, allowing reviewers on any major operating system to assess the work without a local iOS Simulator. Teams can adapt the workflow through GitHub Actions, EAS configuration, an agent prompt defining app context and required evidence, and repository protections that reserve merge decisions for humans; agents are also instructed to report unsuccessful reproduction or verification attempts rather than proceeding with unsupported fixes.

Expo’s limited-access EAS Simulator preview runs remote iOS Simulators and Android Emulators on its infrastructure, streaming supported iOS sessions to browser-based web previews that can be controlled through the CLI, APIs, coding agents, or shared URLs. It aims to remove macOS and physical-device barriers for mobile development by pairing cloud-built simulator development builds with Metro tunneling and Fast Refresh, allowing developers on Windows or Linux, including Windows on ARM through WSL, to edit code locally and view changes on a cloud iPhone. The service supports simulated camera feeds for apps using standard AVFoundation APIs, enabling photo or video injection through the browser, although agents cannot currently control that feature. AI agents can build apps, launch sessions, interact with devices, capture screenshots, and provide session replays as testing evidence, while collaborators can simultaneously view and control shared sessions. EAS Simulator is not limited to Expo or React Native, as it can run iOS Simulator builds and Android APKs from frameworks such as SwiftUI, Kotlin, and Flutter, with access being expanded gradually through a waitlist.

An Expo team member tested whether a full day could be managed using only apps built with Expo’s open-source tools and services, finding that the ecosystem supports a broad range of daily activities including sleep tracking, news, weather, recipes, celebrity messages, navigation, car washes, coding, shopping, running, pet care, photo books, self-reflection, and book selection. Apps such as Rise, Espresso, WeatherWise, Delish, Cameo, Tesla, Replit, Runna, Rover, and Voidpet Garden demonstrated Expo’s versatility across content, commerce, utility, and lifestyle experiences, while an experimental EAS workflow app begun in Replit gained internal interest. The experiment exposed notable gaps in Expo-built messaging, mapping, and camera apps, which the author attributes to network effects for messaging and the challenge of surpassing preinstalled phone tools for maps and cameras. Expo presents these gaps as opportunities for developers and emphasizes its goal of making mobile development more accessible through tools such as its getting-started workflow and EAS Build.

Expo Modules 2.0 introduces a native-first approach to building React Native modules, replacing Expo Modules 1.0’s specialized Swift/Kotlin DSL with ordinary annotated classes, methods, properties, structs, and events. On iOS, developers can use macros such as @ExpoModule and @JS in SDK 57 to expose Swift APIs to JavaScript, while Kotlin-based Android support is still in development and an official documented beta is planned for SDK 58. The approach supports incremental migration alongside the existing API, including an agent-assisted migration skill, and aims to make module development easier for both developers and coding assistants by relying on familiar language syntax and compile-time type checking. By generating bindings from native function signatures at build time, version 2.0 eliminates much of the runtime reflection and allocation overhead of the older API, with reported synchronous-call performance gains of 2.5 to 5.6 times over 1.0 on the tested iOS setup. Planned additions include similarly annotation-based native views, generated TypeScript declarations from native source, and cross-platform checks to identify mismatches between Swift and Kotlin module APIs.

Expo’s documentation team describes Answer Engine Optimization (AEO) as adapting technical documentation for AI coding assistants and answer engines that retrieve live content to answer questions or perform tasks, rather than relying on traditional search rankings or a model’s fixed training data. Its approach includes publishing a concise llms.txt index, offering Markdown versions of pages through content negotiation, URL suffixes, and HTML discovery hints, converting rendered MDX content into reliable Markdown, and adding factual corrections to address outdated model knowledge. The team also uses schema.org JSON-LD generated directly from page content, declares policies for search, AI training, and retrieval use, invites agents to report documentation gaps, and enforces consistent writing with linting. Additional measures include auditing pages with Lighthouse’s Agentic Browsing tools and AFDocs scores, preventing React hydration mismatches that could expose inconsistent page structures, and maintaining a clean accessibility tree for efficient agent interpretation. Although standards and infrastructure may evolve or automate many of these practices, the post argues that accurate, structured, accessible, and consistently maintained documentation remains essential for both human developers and AI agents.