The capability detector should be treated as a versioned contract, not a one-time device check. Model availability, context limits, battery state, and OS policy can change between planning and execution, so every consequential tool call should revalidate capability and permission. I would also keep tool schemas and idempotency keys identical across local and cloud routes; otherwise fallback changes action semantics rather than only the inference location. That makes offline, local, and escalated execution testable with the same scenario suite.
Excellent comparison of how on-device agentic AI is evolving across Android and iOS. I particularly liked the distinction between Android’s modular approach and Apple’s more integrated ecosystem, because the right architecture depends on much more than model capability. Privacy, permissions, tool validation, battery usage, observability, and recovery from failed actions all become critical once an AI can act rather than simply respond. A future article demonstrating the same agent workflow implemented on both platforms would be very valuable.
"The model should never become the application's security boundary" is the line worth anchoring on, typed output and guided generation improve reliability, but neither substitutes for the app independently validating ownership, permissions, and business state. Structured output is a formatting guarantee, not an authorization one.
The Android vs. iOS framing as "modular vs. integrated" rather than "which model is better" is the right lens, AppFunctions being explicitly labeled experimental preview while Apple's Tool protocol ships as a stable native API is a real asymmetry teams should weigh before betting production architecture on either.
Julian Neagu
500+ AI tools shipped solo. Founder of VisionVix.
The security part stood out to me. I’ve seen many AI apps trust the model too much. Tools still need strict rules because the model can make bad calls.