In this talk, we will explore how you can leverage the Android SDK, Jetpack Compose, Kotlin, and other third-party providers to build a unique and delightful experience. 

The goal is to break mental barriers and share what's truly possible on Android. The aim is to inspire you to think beyond conventional UI paradigms and explore new ways to create magical moments for users. 

The talk will cover how one can build UIs that involve the senses and not only the eyes, such as delivering feedback through graphics, haptics, and sounds while the user is interacting with the app. 

Furthermore, we will also touch on AGSL shaders and RuntimeShader to show how boundaries can further be pushed on views for Compose.

What you get:
- The low-hanging fruit on what you can begin with immediately in enhancing your users' experience. 
- A deeper understanding of Android's capabilities that can be utilized to build experiences that feel like magic.
- A grasp of what it takes to get your users fully immersed and have them counting your products as 'must-haves'.

Kenneth Murerwa

Keronei Lincoln

Building Delightful Experiences on Android with Jetpack Compose

UI/UX

Android 16 marks a massive shift in how the OS interacts with installed applications. With the introduction of the android.app.appfunctions package, we are moving away from the rigid deep-linking of App Actions and Slices toward a truly agentic model. Apps are no longer just destinations to be opened; they are headless toolboxes of capabilities that system agents can invoke directly.

In this session, we will move beyond the documentation and dive into the practical implementation of App Functions. We will explore how to wire up an app to expose its features using the new Jetpack androidx.appfunctions library, focusing on the @AppFunction annotation and secure cross-process data handling with AppFunctionSerializable.

Finally, we will look at the other side of the equation: consuming these capabilities. I will demonstrate how to build a custom Android launcher that queries AppFunctionStaticMetadata and natively executes tasks from third-party apps via the AppFunctionManager — effectively turning a standard UI into an AI-ready intent engine.

Key Takeaways:

The Agentic OS Shift: Understand the architectural differences between legacy App Actions and the new headless execution model of App Functions.

Exposing Capabilities: Learn how to implement the androidx.appfunctions Jetpack library, handle KSP code generation, and manage the PlatformAppFunctionService system entry point.

Schema & Serialization: Best practices for defining structured parameters that system agents can easily index and consume.

Live Launcher Demo: A practical walkthrough of querying the on-device index and executing App Functions dynamically from a custom Android launcher.

Dinoy Raj

Agentic Android: Exposing and Consuming Capabilities with App Functions

Case Study

As AI evolves from simple autocomplete to complex agentic partners, Android development is fundamentally shifting. Amidst the industry hype, there is very little hard data on how developers actually interact with these tools day-to-day. What does human-AI collaboration look like in the trenches?

In this 20-minute lightning talk, we move past marketing assumptions to share direct findings from a recent mixed-methods user research study. We’ll decode the realities of AI-assisted building, breaking down the fluid "working modes" that technical and non-technical builders use when partnering with AI. Finally, we’ll uncover the shared aspirations and anxieties of agentic coding.

While these are early insights rather than definitive guidance, examining these behavioral mechanics will give you a framework to evaluate your own workflow and spark vital conversations with your team as you prepare for the next generation of agentic IDEs.

Preethi Srinivas

Beyond the hype: What user research tells us about agentic Android workflows

Other

Mobile developers often focus security effort on the backend, treating the client as a trusted extension of the server. In reality, attackers routinely decompile apps, intercept traffic, and manipulate client-side logic to bypass business rules, extract secrets, and compromise user data — all without touching the server at all. This talk introduces the OWASP Mobile Application Security Verification Standard (MASVS) as a practical framework developers can build against from day one, rather than something a pentester checks at the end of the development cycle. Drawing on real-world penetration testing findings, the session walks through the most common client-side weaknesses ;insecure local storage, weak network communication controls, and insufficient resilience against reverse engineering and how MASVS's control groups map directly to fixes developers can implement early.

Key Takeaways

1. Understand the difference between MASVS (requirements) and MASTG (testing methodology), and how to use both as a developer, not just as a tester.
2. Learn the most common client-side vulnerabilities found in real mobile pentests  and why "the backend validates everything anyway" is a false sense of security.
3. Walk away with a practical, prioritized checklist mapped to MASVS control groups (storage, cryptography, network, platform interaction, resilience) that can be applied to an existing app without a full rebuild.

Experience Level with the Topic:
I'm a Secure by Design Officer at Safaricom with 7 years of experience across security engineering, systems, and penetration testing spanning AWS, Azure, and endpoint security, with a current focus on offensive security and secure development practices. In my current role, I work closely and continuously with developer teams, embedding security requirements into the SDLC rather than treating security as a final gate before release. This gives me a dual perspective: I understand both how attackers actually interact with mobile apps (through hands-on VAPT work using MobSF, Frida, Objection, jadx, and apktool) and how to translate those findings into requirements developers can realistically act on. My background also includes authorized VAPT engagements for banks, SACCOs, insurance firms, and government targets across Kenya, Uganda, Rwanda, and Tanzania, where MASVS/MASTG form part of the compliance and testing frameworks I apply directly. This talk draws on real patterns observed both in client-facing pentest engagements and in day-to-day work helping internal developer teams build security in from the start.

Have you given this talk before?
No ; this would be a first-time delivery of this talk. It's a new session built specifically for this conference, based on patterns observed across recent client engagements.

Keywords:
OWASP MASVS, OWASP MASTG, mobile application security, client-side security, secure mobile development, penetration testing, reverse engineering, mobile app hardening, secure coding, DevSecOps


Cynthia Ateya

Client-Side Security Is Not Optional: Building with OWASP MASVS

Adding an A/B testing SDK to your app takes an afternoon. Shipping a decision you can defend takes two skills most teams only half-learn: engineering the flag infrastructure so it
  produces honest data, and designing and reading the experiment so the data means something. Miss either half and the failure is silent — no crash, no exception, just a dashboard
  that confidently tells you to ship the wrong thing.

 This session walks the full lifecycle of an experiment on Android, drawn from production patterns in a travel app used by millions of travelers monthly, where every feature ships
  behind a flag. In one continuous arc we'll cover both halves:
Running it:
  - Designing a test that can actually answer your question: IF/THEN/BECAUSE hypotheses, one primary metric, guardrails, and a pre-committed duration
  - Reading results with confidence: significance in plain language, mechanism metrics that explain what the headline number can't, and the peeking trap

  Engineering it:
  - One experimentation abstraction over Statsig: type-safe keys, a single injected interface, gates vs. experiments behind one call site
  - Cold start done right: async init and deterministic defaults, so the UI never blocks or flickers between variants
  - Resolving variations once in your MVI reducer / ViewModel — and exposure logging at the moment of view, not assignment
  - The debt side: testing every arm, QA overrides, and deleting dead flags before they rot your codebase

 Woven through the whole session: I'll walk you through several pain points every experimenting team eventually hits (underpowered tests, peeking, variant flicker, diluted exposure, sample ratio
  mismatch, colliding experiments, and more), candid takeaways from years of running experiments in production, and a take-home checklist of the practices that make an A/B test succeed -  before you build, while you build, while it runs, and after it ends.

  No prior experimentation experience needed. If you've never run an A/B test, this session is designed as your on-ramp; if you run them every week, you'll recognize the scars and leave with an architecture you can implement next sprint.

Key learning points

1. Design a trustworthy experiment before writing any code: an IF/THEN/BECAUSE hypothesis, one primary metric, guardrail metrics that protect what you're not trying to move, and a
  pre-committed duration.
2. Architect a single experimentation abstraction over any SDK (Statsig used for concreteness): type-safe feature keys, one injected interface, gates vs. experiments behind one call site — testable, vendor-portable, and with one place for policy like defaults and kill switches.

3. Handle the mobile-specific engineering edges: async cold-start init with deterministic default-to-Control (no blocking, no flicker, no mid-session variant swaps), variations resolved exactly once in the MVI reducer and driven through immutable state into Compose.

4. Log exposure honestly — assignment is not exposure: manual exposure events for below-the-fold and conditional components, and how getting this wrong dilutes real effects until a harmful variant reads as "neutral, ship it."

5. Read results and close the loop: what statistical significance means in plain language, why mechanism metrics explain what the primary metric can't, the peeking trap that flips decisions, and the cleanup ritual — test every arm, own every flag, delete the loser the week you decide.

Harny Otuoniyo

From Flag to Decision: Engineering and Running A/B Tests on Android You Can Actually Trust

In this talk, discover how One Acre Fund serves over 1 million farmers with bulletproof mobile apps that thrive without a network connection. We’ll dive into a production-proven, offline-first CQRS architecture powered by Couchbase Lite on Android and Couchbase Server. Learn how separating your read and write models into distinct local databases eliminates connectivity issues, provides zero-latency user experiences, and simplifies edge synchronization via WebSockets. 

Designed for Android and backend engineers, this session unpacks the complete data flow from local command queues to remote reconciliation. You’ll walk away with practical patterns, real-world trade-offs, and the ultimate blueprint for resilient, edge-first applications.

Ian Okumu

Instant Everywhere: Decoupling the Network for Zero-Latency Mobile Apps

Perfomance

Most Android developers draw a hard line at the edge of the app. The backend is "someone else's problem" .  Node.js, Python, whatever the backend team uses. But what if that line didn't have to exist?

This session is a case study of Affirmi, a production wellness app built entirely in Kotlin , from a Kotlin Multiplatform client targeting Android, iOS, Web, and macOS, to a Ktor backend that handles AI orchestration, machine learning, push notifications, and subscription management.

I'll walk through the real architecture, the real tradeoffs, and the real problems that came up — not a toy example, but a shipped product.

What we'll cover:

1. The Full-Stack Kotlin Architecture How KMP shares business logic, domain models, and networking across four platforms without compromise. What belongs in shared code, what doesn't, and how the Ktor backend became the intelligence layer the client simply calls.

2. AI Orchestration on the Server Why the LLM should never freely decide what content a user gets. Affirmi's backend uses a spec-first generation pipeline: a scoring function determines the affirmation's tone, theme, and emphasis based on the user's emotional profile — the LLM just renders it. I'll show the actual PromptBuilder, AffirmationSpec, and RankingService code.

3. The ML Personalization Loop Affirmi learns what each user responds to. I'll walk through the full feedback loop: how interaction events (likes, skips, plays) flow from the client to Firestore, get transformed into training samples, and feed a per-user affinity model that changes what the next affirmation looks like. No ML framework required — just smart data engineering and a well-designed scoring function.

4. Server-Side Push Notifications with Ktor Daily personalized affirmations are pushed at the user's chosen time via a coroutine-based scheduler running inside the Ktor process. No Cloud Scheduler. No Firebase Functions. No TypeScript. I'll show the NotificationScheduler, the idempotency design, FCM fan-out, and stale token handling — all in Kotlin.

5. RevenueCat on a KMP + Ktor Stack How to integrate RevenueCat subscription management across Android and iOS from shared KMP code, why you should never hardcode prices in your UI (and what happens when you do), and how the backend validates entitlements without duplicating logic.

The honest part: I'll also talk about what went wrong — the architecture iterations, the over-engineering temptations, the phases where the agent-assisted development added complexity faster than it added value, and what I'd do differently if starting today.

Bill Odida

Kotlin Everywhere: KMP, Ktor, and ML in a Real Production App

**Open Source as an Alternative to Proprietary Software in Low-Income Communities**

What role can open source play in making digital services more accessible, affordable, and locally owned? This talk explores that question through the story of **OpenRide Africa**, an open-source ride-hailing platform being built by Kenyan engineers. Designed to provide a transparent and community-driven alternative to proprietary ride-hailing solutions, OpenRide Africa demonstrates how collaborative software development can address local challenges while creating opportunities for innovation.

The session will cover the motivation behind the project, the steps taken to build it, the technical and community challenges encountered, and the opportunities it creates for developers to contribute to software with real-world impact. Attendees will gain practical insights into how open source can reduce barriers to technology adoption, foster local talent, and support sustainable digital ecosystems in low-income communities across Africa.

Musyoka Muasya

Open source as an alternative to proprietary software in low-income communities

Every AI chat app you've used ChatGPT, Claude, shows words appearing one at a time instead of freezing then dumping a full paragraph on screen. That's streaming, and it's the difference between an app that feels alive and one that feels broken.

This talk shows how to build that experience properly in Kotlin, using tools you already know. We'll model an AI response as a Flow, wire it into StateFlow for clean loading/streaming/error UI state, and handle the part most examples skip entirely: what happens when a user cancels mid-response. Without proper structured concurrency, that request keeps running in the background — burning API cost and battery for an answer nobody will see. With it, cancellation is nearly free.

We'll also cover retry and error handling when a stream drops mid-response (a real, common failure mode with LLM APIs), and briefly touch on backpressure — what happens if your UI can't keep up with how fast tokens arrive.

Jeremy Gitau

Streaming AI Responses with Kotlin Flow

Something fundamental is changing in mobile engineering. For years, our job was translating ideas into code. Today, AI tools do that in seconds. But there is a catch. These assistants write code with absolute confidence, yet they often hide subtle bugs, fragile architecture, and silent failures. When writing code is no longer the bottleneck, what makes a developer valuable? The answer is judgment. The defining skill of our era is no longer writing code, but critically evaluating it.
This keynote explores how to build your "developer taste." It is the instinct that separates code that simply compiles from code that survives the real world. At first, reviewing AI output feels like a slow, exhausting audit. But with practice, it becomes a sharp, automatic reflex. We will look at how to spot hidden traps in confident AI answers and build systems you can trust. You will walk away knowing how to harness the massive speed of AI without ever lowering your engineering standards.


Michael Bukachi

The Evaluator’s Edge: Cultivating Developer Taste in the Age of AI

Most screens built with AI tools look the same: purple gradients, rounded cards and vague copy. This happens because the AI only gets a short text prompt, so it falls back on the most common patterns it has seen. In this talk, I show how to give it something better to work from. Using Figma's MCP server, which lets AI tools read your Figma file directly, I walk through how to set up your designs so the AI follows your colours, fonts, spacing and components, then build a working screen live from a Figma frame. You will learn how to spot generic AI-made UI, how to prepare your files, and where a designer still needs to step in. You will leave with a simple checklist for your next project.

Speakers