Conferencing

The largest flutter-focused developer conference in Africa

flutterconKe

fluttercon

Fluttercon Ke & DroidconKe 2026

Welcome & State of the Community

Start your conference by building something & win KES 42,000. 
The challenge is revealed when the session starts. Form a team of up to three, or join one in the room, and get 40 minutes to build. It can be a tool, library, plugin, component or prototype that makes life better for mobile developers or the people using their apps. Think developer experience, accessibility, performance, offline-first, testing, or anything else that removes friction. Any stack is welcome: native Android, iOS, Kotlin Multiplatform, Flutter, React Native. AI coding tools are allowed.
Bring a charged laptop and a teammate (or find one there). 
Leave with a project, new collaborators and maybe the prize.

Brian Odhiambo

Build Before Breakfast : Hackathon by Thamani®

Other

Break

Most Flutter performance advice stops at basic surface-level tips; like adding `const` constructors or minimizing `setState` calls. However, in complex production applications, severe performance bottlenecks usually stem from low-level issues: shader compilation jank, unmanaged image caching, heavy garbage collection spikes, and inefficient widget tree rebuilds under load.

This session cuts through surface-level advice to explore the internals of Flutter’s rendering pipeline and engine architecture. We will dissect how Impeller changes rendering execution, examine real-world CPU and GPU flame graphs, identify subtle memory leaks, and showcase actionable profiling strategies using Flutter DevTools. Attendees will leave with practical architectural patterns to systematically benchmark, profile, and guarantee 60/120 FPS performance across budget Android hardware and high-end iOS devices.

Key Takeaways & Learning Points:
1. Impeller vs. Skia Deep Dive: Understanding Impeller's rendering pipeline and pre-compiled shaders to eliminate dropped frames.
2. Mastery of Flutter DevTools: Practical techniques for interpreting CPU profiles, memory allocation traces, and raster thread bottlenecks.
3. Memory & Asset Optimization: Architectural patterns for managing large image caches, reducing GC churn, and preventing memory leaks.
4. CI/CD Performance Gateways: Setting up automated performance regression benchmarking in CI/CD pipelines to catch frame drops before production.

Experience Level: Intermediate to Advanced (tested on production applications deployed across diverse device specs).
Previous Presentation History: New session created specifically for FlutterCon Kenya 2026.

Keywords: Flutter Performance, Impeller, DevTools, Memory Optimization, Profiling, Raster Thread, Benchmarking, Mobile Engineering

Brian Mukwambo

Beyond const: Production-Grade Performance Profiling & Impeller Optimization in Flutter

Perfomance

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

Lunch Break

Traditional Flutter integration testing often involves writing and maintaining large amounts of test code that can become brittle as applications evolve. As AI agents become more capable, a new approach is emerging, one where developers describe expected behaviour in natural language and intelligent agents execute and validate those scenarios automatically.

In this session, we'll explore how to build agentic integration testing workflows for Flutter applications by combining Gherkin(BDD) with the Marionette Model Context Protocol (MCP). You'll learn how to configure the Gherkin skill which utilises the Marionette MCP, enable AI agents to understand and execute Gherkin scenarios on real devices, and validate application state without writing conventional integration test code.

Beyond demonstrating the workflow, we'll look at how teams can create reusable, codebase-specific skills that encapsulate common application behaviours, making AI-driven testing faster, more reliable, and easier to adopt across projects.

Whether you're looking to reduce the maintenance burden of traditional integration tests or explore the next generation of AI-assisted developer workflows, this session provides practical techniques you can apply immediately.

Learning Objectives

- Learn how to install, configure, and use the Marionette MCP with AI agents for Flutter development.
- Discover how Gherkin scenarios can drive fully agentic integration tests on real devices.
- Build reusable, codebase-specific skills that streamline testing and automate common engineering workflows.

Key Takeaways

- Build and run a zero-code, AI-powered Flutter integration testing pipeline.
- Design reusable agent skills that automate repetitive testing workflows.
- Understand how MCP-enabled agents can improve the speed, reliability, and maintainability of Flutter integration testing.

Sebastine Odeh

The Agentic Shift: Building Zero-Code Flutter Integration Tests with Gherkin and Marionette

Testing

I rewrote a Flutter app to native Android with Kotlin and Jetpack Compose — same features, same Supabase backend, completely different architecture. Here in the real code we address what got simpler, what got harder, and the build-time cost nobody warns you about.

Flutter got my app to market fast on two platforms with one codebase. But after maintaining it for a while, I rewrote it — screen by screen, package by package — into native Android with Kotlin and Jetpack Compose. Not a plugin sunset, a full rewrite.

This talk is a practical, code-level comparison of both codebases side by side: same app, same offline dataset, same Supabase backend, two completely different architectures. I'll walk through:

- Dependencies as a map of the architecture
- Dependency injection
- State management
- Concurrency
- Navigation and theming
- What native actually bought me
- The trade-off nobody mentions

This isn't a "Flutter bad, native good" talk. It's a grounded look at what changes — for better and worse — when you move the same product across two very different architectures, from someone who actually did the rewrite rather than theorized about it.

Siro Devs

Rewriting My Flutter App to Native Android: A Side-by-Side Architecture Breakdown

Libraries

Integrating real-time communication into a mobile application can feel like navigating a minefield of latency issues, signaling servers, and complex peer-to-peer connections. In this session, we will demystify WebRTC within the Flutter ecosystem. Moving beyond simple chat apps, we will dive into the architecture required to build robust VoIP features and seamless screen-sharing capabilities. Using real-world examples, we’ll break down how to establish peer connections, handle video/audio tracks, and broadcast screens efficiently across devices.

Key Takeaways & Learning Points:
By the end of this session, attendees will learn:

The WebRTC Lifecycle in Flutter: A clear understanding of Signaling, ICE Candidates, and Peer Connections.

Implementing Screen Sharing: Step-by-step techniques for capturing and transmitting screen data using flutter_webrtc.

State Management for Real-Time Media: How to cleanly manage the complex state of active calls, camera toggles, and screen casting without UI stutter.

Production Pitfalls: Common challenges with NAT traversal (STUN/TURN servers) and how to ensure reliable connections in poor network conditions.

My Experience with this Topic:
I am a Mobile & Software Engineer and Team Lead who actively architects and deploys cross-platform applications. My experience with this topic comes from hands-on, production-level development, specifically building robust VoIP and SIP applications for enterprise use.

Have you given this talk before?
No, this will be a premier talk specifically tailored for the Fluttercon Kenya audience.

Jerome Jumah

Real-Time Collaboration: Mastering WebRTC & Screen Sharing in Flutter

When you add AI to your app, every request has to run somewhere: on a server in the cloud, or on the user's phone. Cloud models are powerful, but you pay for every request and they need a network connection. On-device models are private, free to run, and work offline, but they are small and limited. Neither one is the right choice for everything. The better approach is to decide per request. That decision is just Dart code, and this session shows you how to write it.

First, we'll look at what should drive the decision, using simple examples. A request with personal data should stay on the phone. A complex planning question needs a bigger cloud model. A basic lookup can be answered locally for free. And when there is no network, the on-device model is the only option. Then we'll write the routing code in Dart, step by step. We start with a simple if/else that picks a model. Next, we use a tiny local model to classify each request and route it. Finally, we build a small fallback service, so the feature keeps working when the network or a provider fails. The examples use Genkit, with Gemma on the device and Gemini in the cloud.

We'll finish with what it takes to ship this: what small models can and cannot do today, how to test routing logic, and how to get a large model file onto users' phones.

Key takeaways:

- How to decide, for each request, whether it should run on-device or in the cloud
- The four signals behind that decision: privacy, connectivity, cost, and capability
- Dart code for three levels of routing, from a simple if/else to a fallback service
- What shipping an on-device model involves: model download, cold start, memory limits

For Flutter and Dart developers at any level. No AI experience needed. The ideas apply to any platform.

Jamiu Okanlawon

Offline-First, Cloud-Smart: Hybrid AI in Flutter

Wrapping Up & Key Takeaways

Welcome & Upcoming Today

Shipping the same product on several platforms comes with a promise: it will behave the same everywhere. Smile ID ships identity verification as four SDKs, for Android, iOS, Flutter and React Native, in four languages, and partners expect one experience from all of them.

This session is the playbook we use to keep that promise, and it applies to any team maintaining one product across several stacks. Keep the public surface small and identical, so you can change how things work inside without partners touching their code. Build the hard parts, such as the camera and the screen flow, once per platform and share them, instead of borrowing a different plugin for each framework. Write the rules that must match as data your builds check, not as conventions people remember. Keep a record of the differences you keep on purpose. Test and release every platform in step.

You'll leave with a checklist you can apply, whatever your stack.

Harun Wangereka

Contracts, not conventions: keeping one promise across Android, iOS, Flutter and React Native

With Flutter’s definitive transition to the Impeller rendering engine, the ecosystem has achieved a predictable, ahead-of-time (AOT) shader-compiled execution model. However, hitting a rock-solid, fluid 120fps on modern high-refresh-rate Android devices requires  engineers to shift how they diagnose, isolate, and fix rendering bottlenecks.

This session bypasses high-level UI paradigms to dissect exactly how Impeller interacts with the modern Vulkan graphics API on Android 10+ (API 29+). We will dive into how Impeller schedules GPU pipelines, uses modern tessellation to break vector paths into fast-rendering triangles, and manages explicit command buffers to prevent frame drops under heavy stress loads.

we will intentionally thrash a real-time graphics canvas and step through deep-dive profiling. 

Attendees will learn how to parse advanced Flutter DevTools Timeline traces, interpret Android Systrace/Perfetto metrics, and engineer surgical UI optimizations—such as precise repaint boundary isolation and layer complexity reduction—to confidently ship enterprise-grade mobile experiences.

Key Takeaways:
- Demystifying the Engine: Understand the architectural differences between Skia’s JIT shader compilation and Impeller’s AOT pipeline mechanics on Vulkan.
- Low-Level Profiling: Master advanced Flutter DevTools and Android Systrace to read frame-budget allocations (~4ms UI / ~4ms Raster thread).
- Taming Custom Painters: Learn code patterns that maximize Impeller's pre-compiled rendering pathways, avoiding expensive canvas operations like saveLayer().

Collins Munene

Beyond Skia: Deep-Dive GPU Scheduling and Profiling with Impeller on Android 10+

Agents are moving from demos into everyday developer workflows. This keynote looks at where Android is heading: agent-ready tooling and builds, Android skills and the Android CLI that give any agent Google’s own guidance on the areas models still get wrong, on-device intelligence with Gemini Nano, and what it takes to ship secure, high-quality apps when agents write part of the code. Expect a view from the Android team at Google, fresh from Android Dev Summit, and practical takeaways whether you build with Kotlin, Flutter or anything in between.

Chris Assigbe

Android in the Agentic Era

When we start with Flutter, widgets feel like magic. They cover most of our use cases—until one day the design team comes up with something that just doesn’t fit inside the widget box. That’s when CustomPainter enters the picture.

In this talk, I’ll share how CustomPainter gives you complete control over the canvas and allows you to create visuals that are simply not possible with standard widgets. I’ll walk you through how I used it in a real production feature—from drawing and manipulating paths to converting an SVG into custom path data. Along the way, we’ll also touch on some simple vector concepts that make life easier when working with shapes and curves.

The goal is not just to show cool graphics, but to teach you how to structure your drawing logic, how to keep performance in mind, and how to break down a complex idea into smaller, manageable pieces. By the end, you’ll feel confident about picking up CustomPainter the next time your app’s design demands something unique.

I’ll also walk through my experience of implementing CustomPainter in the AMEX Lounge app, where we had to design premium card visuals and dynamic graphics that demanded pixel-perfect accuracy. From breaking down complex drawings into smaller reusable parts, to ensuring smooth performance on high-density screens, you’ll learn what it really takes to use CustomPainter effectively in production.

This session is not just about code—it’s about building confidence to pick up CustomPainter when your design vision doesn’t fit inside a widget box.

Key Takeaways

- Clear understanding of how CustomPainter works and when it makes sense to use it.
- Step-by-step process of turning SVG paths into Flutter-friendly drawings.
- Easy-to-grasp vector basics that you can apply in your own code.
- Practical tips on breaking complex drawings into smaller, testable parts.
- Ideas and inspiration to go beyond widgets and build interfaces that stand out.

Mrinal Jain

Shaping the Impossible: Production-Ready CustomPainter Techniques

Standard Flutter AI tutorials typically follow a predictable formula: capture a photo, transmit it to a remote API, and present the output. While this architecture operates smoothly under ideal conditions, it fails during API outages, over slow 2G connections, or when developing for agricultural environments where cloud dependence becomes a fundamental product risk rather than just a poor user experience.

This session introduces an alternative architecture by demonstrating how to build a Flutter application that runs a crop disease classifier locally on the device. Powered by the flutter_litert plugin, the app utilises LiteRT - Google’s on-device AI runtime, formerly known as TensorFlow Lite. It stores recent predictions in Hive for offline access and relies on connectivity_plus to automatically detect network changes, transitioning seamlessly to a FastAPI backend when connectivity is available without any user-visible interruption.

We will cover the end-to-end pipeline: exporting a PyTorch model for on-device inference, writing the preprocessing pipeline in Dart that matches the Python training pipeline exactly (a mismatch here silently ruins accuracy, and we will look at what that failure actually looks like), integrating the LiteRT interpreter with correct tensor shape and normalisation handling, and building a prediction service that abstracts over on-device and backend inference so the UI never knows which one it is using.

Additionally, we will examine the integration seam for a RAG-driven chat functionality following disease identification. Rather than building the actual RAG pipeline live on stage, our focus will centre on the architectural contract between the Flutter client and the remote system, demonstrating how the application queries a backend RAG service to provide users with well-grounded, source-cited responses when they ask "what do I do about this?"

Attendees will walk away with a production-grade Flutter mobile AI architecture capable of robust offline operation and graceful degradation, backed by solid benchmark data to validate each architectural choice.

Paul Mburu

Titus Kariuki

Beyond the API Call: On-Device AI in Flutter with LiteRT and Offline-First Architecture

Case Study

Keeping mobile apps fresh in production is no small feat, especially when you need to iterate fast and the app stores review queues, approval delays, and multi-day waits can't keep up. We've all been there.

In this session, I’ll walk you through how my team at BasiGo tackled this challenge by integrating Shorebird, an open-source tool that brings over-the-air (OTA) updates to Flutter apps. With Shorebird, we’re able to push critical fixes and small improvements directly to users without waiting on app store approvals or breaking our CI/CD flow.

We’ll cover:
 1). What Shorebird is and how it works under the hood
 2). How to integrate it into a production Flutter app with minimal friction.
 3). How we use it alongside Codemagic for tagging, versioning, and automated rollouts.
 4). Lessons learned from deploying OTA updates in a live environment.
 5). Why OTA isn’t just a dev-time win, but a product win too.

Whether you're a solo dev, scaling a startup, or just tired of staring at Play Console submission statuses, this session will help you ship smarter, faster, and with more confidence.

Emmanuel Bonke

Shipping Faster with Shorebird: Production-Ready OTA Updates for Flutter Apps

Ever needed a native feature in your Flutter app, only to realize you don't know Kotlin or Swift? You head to pub.dev hoping someone's already solved it but the package that's out there doesn't quite do what you need.

The good news: you don't need to leave Dart to fix this.

This talk explores direct native interop in Flutter using JNIgen and FFIgen - tools that let you call native Android and iOS APIs straight from Dart, skipping the boilerplate of method channels and hand-written native code entirely. Attendees will leave with a practical understanding of when to reach for JNIgen vs FFIgen, how the code generation actually works under the hood, and how to wire up a real native call end to end.

Key takeaways:

- Why method channels aren't always the right tool, and when native interop makes more sense
- How JNIgen and FFIgen generate Dart bindings from native APIs
- A live/walkthrough example of consuming a native Android or iOS API directly from Dart

Sessions

6:30 am - 7:00 am · fluttercon

7:00 am - 8:00 am · fluttercon

8:00 am - 8:10 am · fluttercon

8:10 am - 8:50 am · fluttercon

8:50 am - 9:00 am · fluttercon

9:00 am - 10:00 am · fluttercon

10:00 am - 11:00 am · fluttercon

11:20 am - 12:10 pm · fluttercon

12:10 pm - 12:20 pm · fluttercon

12:20 pm - 1:30 pm · fluttercon

1:30 pm - 1:40 pm · fluttercon

1:40 pm - 2:20 pm · fluttercon

2:20 pm - 2:30 pm · fluttercon

2:30 pm - 3:10 pm · fluttercon

3:20 pm - 3:50 pm · fluttercon