DEV Community: Muhammad Uzair

The Future of Mobile DevOps: AI Testing & Auto-Healing

Muhammad Uzair — Sun, 15 Nov 2026 03:01:16 +0000

The Future of Mobile DevOps: AI-Driven Testing and Auto-Healing Pipelines

Mobile DevOps has historically been the most painful area of mobile engineering. Managing provisioning profiles, dealing with flaky UI tests, and handling infinite device fragmentation makes continuous deployment feel like a pipe dream.

But in 2026, the landscape has shifted. AI is no longer just a buzzword; it is an active participant in our deployment pipelines.

The Death of Brittle UI Tests

Traditionally, QA engineers wrote UI tests using explicit XPath or accessibility ID locators. If a designer moved a button or changed a class name, the test broke. This resulted in "flaky" test suites that developers eventually ignored.

Enter Auto-Healing Tests:
Modern mobile DevOps platforms utilize machine learning to understand the intent of a test. If an element's ID changes, the AI analyzes the DOM tree, visual characteristics, and context to dynamically identify the new element and update the test locator automatically. This reduces test maintenance overhead by up to 80%.

Predictive CI/CD Routing

Instead of running an exhaustive 2-hour test suite on every single commit, AI-driven pipelines analyze the code diff to predict which tests are most likely to fail.
If a developer only changes the "SettingsScreen.tsx" file, the CI intelligently subsets the test suite to only run settings-related E2E tests, dropping the PR feedback loop from hours to minutes.

Automated Rollbacks

If a release hits production and crash reporting tools detect a 5% spike in ANRs (Application Not Responding), the modern DevOps pipeline doesn't wait for a human to wake up. It automatically halts the staged rollout on Google Play and Apple App Store and rolls back to the previous stable version, sending an alert to the engineering team.

Mobile DevOps is finally catching up to backend deployment standards, allowing teams to ship faster, safer, and smarter.

Originally published at uzairxdev.online

Build an Arrow Puzzle Game in Flutter

Muhammad Uzair — Sun, 15 Nov 2026 03:00:08 +0000

When I built KnotGlide, a calm arrow puzzle game, the whole game rested on one simple move: tap an arrow whose path is clear and it glides out of the maze along its own route. A blocked arrow nudges forward and shows what is in its way, so every tap teaches the next move. The game ships with 100 curated levels in 8 chapters, a daily puzzle, time challenges and an endless mode — all fully offline, with no account and no purchases. You can see the finished game in the KnotGlide case study.

This guide shows how to build that kind of game in Flutter: model the board as plain Dart data, write the clear-path check, animate the glide, handle ambiguous taps fairly, design levels that are always solvable, and add a daily puzzle with streaks — all on-device, with no network at all.

What is an arrow-escape puzzle game?

An arrow-escape puzzle game is a grid puzzle where every piece is an arrow pointing in one of four directions, and the only move is tapping an arrow to slide it out of the board along the direction it points. An arrow escapes only when every cell between it and the edge of the board is empty; if another arrow blocks the way, the tapped arrow nudges forward and shows what is in its way instead of moving. The level is complete when every arrow has escaped, and the puzzle is in the order: freeing one arrow can open the path for another, so the player has to find the right sequence. That is the whole ruleset — no dragging, no rotating, no matching — which is why the game stays calm and readable even on a crowded board. Boards in KnotGlide come in many shapes, including circles, hexagons, rings, diamonds, leaves and hourglasses, but under the hood each one is still a grid of cells, so the same code drives every shape.

Model the board as plain Dart data

Model the board as plain Dart data before any widget touches it, because every other part of the game — the escape check, the animation, the save system — reads from the same model. A board is a grid of cells, and each cell either holds an arrow or is empty. An arrow knows its row, its column and the direction it points, and a direction knows how to step one cell: up subtracts a row, down adds a row, left subtracts a column and right adds a column. Keep the model free of widgets, colours and animation state so you can test it in plain Dart unit tests, generate levels from it, and serialize it for saving mid-level progress.

\`dart
enum Direction { up, down, left, right }

extension DirectionStep on Direction {
(int, int) get step => switch (this) {
Direction.up => (-1, 0),
Direction.down => (1, 0),
Direction.left => (0, -1),
Direction.right => (0, 1),
};
}

class Arrow {
Arrow({required this.row, required this.col, required this.direction});

int row;
int col;
final Direction direction;
}

class Board {
Board({required this.rows, required this.cols, required this.arrows});

final int rows;
final int cols;
final List arrows;

bool isInside(int row, int col) =>
row >= 0 && row < rows && col >= 0 && col < cols;

Arrow? arrowAt(int row, int col) {
for (final arrow in arrows) {
if (arrow.row == row && arrow.col == col) return arrow;
}
return null;
}
}
`\

Non-rectangular boards need no special case: mark some cells as walls and isInside returns false for them, keeping one code path for every shape in the game.

How do you check whether an arrow can escape?

An arrow can escape when every cell between it and the edge of the board, in the direction it points, is empty. Walk from the arrow one cell at a time in its direction: if you step outside the board, the path is clear; if you meet another arrow first, the path is blocked. The check is a short loop and the single source of truth for the whole game — the tap handler, the hint system and the level solver all call the same function. When the path is blocked, do not just ignore the tap: nudge the arrow a few pixels toward the blocker and back, so the player sees exactly what is in the way.

\`dart
bool canEscape(Board board, Arrow arrow) {
final (dRow, dCol) = arrow.direction.step;
var row = arrow.row + dRow;
var col = arrow.col + dCol;

while (board.isInside(row, col)) {
if (board.arrowAt(row, col) != null) return false;
row += dRow;
col += dCol;
}
return true;
}

void tryEscape(Board board, Arrow arrow) {
if (canEscape(board, arrow)) {
board.arrows.remove(arrow);
} else {
// Play the nudge animation: the arrow shows its blocker.
}
}
`\

The hint system is the same function run over every arrow: scan the board, collect the arrows where canEscape returns true, and light one of them up. In KnotGlide the hint lights up an arrow that can escape right now, so it never suggests a move the game itself would refuse.

How do you animate the glide?

Animate the glide with an AnimationController and a Tween between the arrow's current cell and the board edge, so the arrow travels along its own route instead of teleporting out. Scale the duration to the distance — about 90 milliseconds per cell, capped at roughly half a second — so a short hop feels snappy and a long glide across the board still feels fast. Draw the board with a CustomPainter and render each arrow as a positioned widget on top of it, so the animation moves the widget while the painter stays still; the Flutter documentation for CustomPainter shows the pattern. When the animation completes, remove the arrow from the board model and rebuild. Respect the player's reduce-motion setting: when MediaQuery disables animations, skip the tween and remove the arrow immediately, because a calm game should never force motion on someone who asked for less of it. In KnotGlide the reduce-motion, haptics, sound and music switches are separate, so a player can silence the game without losing the feedback they do want. If you are new to Flutter animation, the breathing pacer guide walks through AnimationController and curved tweens in a smaller example.

\dart Future<void> animateEscape({ required AnimationController controller, required int distance, required VoidCallback onDone, }) async { final duration = Duration(milliseconds: (distance * 90).clamp(120, 500)); controller.duration = duration; await controller.forward(from: 0); onDone(); } \\

How do you make taps feel fair?

Make taps feel fair by never guessing when a tap is ambiguous. On a crowded board a fingertip can sit between two arrows, and picking the wrong one punishes the player for the game's imprecision. When a tap lands near more than one arrow, light both of them up and let the player choose — the tap becomes a selection, not a mistake. KnotGlide uses exactly this rule: a tap between two arrows never guesses, both glow and the player chooses. Add an optional Tap Twice mode on top of it: the first tap previews the escape path, highlighting every cell the arrow would travel through, and the second tap sends it out. The preview costs nothing to implement — it reuses canEscape and draws the path — and it turns the most frustrating moment in the game, tapping an arrow that cannot move, into a deliberate choice. Three hearts per level give the player room to learn: a blocked tap costs a heart, and the level ends when the hearts run out.

How do you design levels that are always solvable?

Design levels that are always solvable by building them backwards from the solved state. Start with an empty board, place arrows in reverse escape order — the last arrow to escape goes in first, then the arrow that blocks it, and so on — and every level you build this way has at least one solution by construction. Author each level as a small grid of characters, one character per cell, where a letter marks an arrow and its direction and a dot marks an empty cell; the level file stays readable and editable by hand. Then verify every level with a solver in your tests: the solver tries each escapable arrow in turn, recurses, and reports any level with no solution, so a broken level never reaches the player. Difficulty comes from the number of arrows and how many of them block each other, not from new rules: early chapters use three or four arrows with obvious first moves, later chapters pack the board so the player has to plan several moves ahead. KnotGlide ships 100 curated levels across 8 chapters — Loose Threads, First Knots, Twists, Tangles, Grand Knots, Snarls, Labyrinths and Gordian Knots — with an endless mode after level 100. A Perfect Glide star for clearing a level with no blocked taps gives skilled players a reason to replay.

How do you add a daily puzzle and streaks?

Add a daily puzzle by deriving the puzzle from the date instead of storing a list of puzzles. Use the current date as a seed — for example, the number of days since a fixed start date — and generate or pick the board from that seed, so every player in the world gets the same puzzle on the same day and the puzzle changes at midnight without any server. Store the streak on-device: the last date the player completed a daily puzzle and the current streak count. When the player finishes today's puzzle, compare the stored date with yesterday: if it matches, add one to the streak; if it is older, reset the streak to one; if it is today already, do nothing, because replaying a finished puzzle should never inflate the streak. Monthly trophies are the same idea at a larger scale — count completed days in the current month and award a trophy at fixed thresholds. Keep past days playable, as KnotGlide does, so a missed day never locks a player out.

\`dart
Future recordDailyPuzzle({
required DateTime today,
required DateTime? lastPlayed,
required int currentStreak,
}) async {
final yesterday = today.subtract(const Duration(days: 1));
final isSameDay = lastPlayed != null &&
lastPlayed.year == today.year &&
lastPlayed.month == today.month &&
lastPlayed.day == today.day;

if (isSameDay) return;

final isYesterday = lastPlayed != null &&
lastPlayed.year == yesterday.year &&
lastPlayed.month == yesterday.month &&
lastPlayed.day == yesterday.day;

final newStreak = isYesterday ? currentStreak + 1 : 1;
// Save newStreak and today with shared_preferences.
}
`\

How do you keep progress safe and the game calm?

Keep progress safe by saving the board state after every move, so a player who closes the app mid-level resumes exactly where they left off. Serialize the model you already built — the list of arrows with their positions and directions, the hearts left, and the level id — into a small JSON map and write it to on-device storage. Loading is the reverse: read the map, rebuild the board, and the player never notices the app restarted. Keep the game calm by removing pressure from the main levels: no timer, no ads between levels and no banners, with rewarded ads only when the player chooses — for a hint, an extra heart or more seconds in a time challenge. Time challenges are a separate mode with their own rules, so the 12 challenges with up to 36 stars in KnotGlide never leak a countdown into the relaxed levels, and a blocked tap there costs 5 seconds instead of a heart. Light and dark themes, separate sound, music and haptics switches, and pinch-to-zoom on big boards round out the experience. The same on-device, offline-first thinking works for any calm app — the color-blind friendly game guide shows how accessibility choices like symbols alongside colours shape a game from the start.

Get in touch and let's talk about your project.

Originally published at uzairxdev.online

Designing Inclusive Mobile Apps: Accessibility Done Right

Muhammad Uzair — Sat, 14 Nov 2026 03:07:00 +0000

Designing Inclusive Mobile Apps: Accessibility Beyond Just Contrast Ratios

When developers hear "accessibility," they often think of automated Lighthouse scores or ensuring text has a 4.5:1 contrast ratio. While these technical specifications are important, they barely scratch the surface of true inclusive design.

Building an accessible mobile app means recognizing that your users are navigating the digital world with varying levels of vision, hearing, motor skills, and cognitive processing.

1. Dynamic Type and Layout Fluidity

Many developers hardcode font sizes, assuming users will view the app exactly as it appears in Figma. This completely breaks when a visually impaired user increases their system font size by 200%.

Best Practice:
Never use fixed heights for text containers. Allow your UI to wrap and flow dynamically. If a user sets their system text to maximum, your elegant single-line button might need to become a multi-line, stacked layout. Embrace the fluidity.

2. The Nuance of Screen Readers

Testing with VoiceOver (iOS) or TalkBack (Android) should be a mandatory part of your QA process.

Avoid using vague labels like "Click Here".
Use "aria-hidden" or "excludeFromSemantics" on purely decorative images so the screen reader doesn't waste the user's time reading out useless file names.
Group related elements together. If you have a custom card with a user's name, avatar, and bio, the screen reader should read it as a single cohesive unit, not three disconnected pieces of data.

3. Designing for Motor Impairments

Not everyone can perform precise gestures or reach the top corners of massive modern smartphones.

Touch Targets: Ensure every tappable element is at least 44x44 points.
Gesture Alternatives: If your app relies heavily on complex swipe gestures, always provide a simple button alternative for users with limited dexterity.

Inclusivity isn't a post-launch "nice-to-have." It is a fundamental architectural decision that expands your user base and improves the UX for absolutely everyone.

Originally published at uzairxdev.online

Flutter Role-Based Access Control Guide

Muhammad Uzair — Sat, 14 Nov 2026 03:05:33 +0000

When I built the Muntazim Parent App, a school management app for parents, one requirement shaped the whole architecture: a parent must see only their own child's attendance, grades and fee status, never another family's data. Teachers see their classes, school admins see everything, and parents see exactly one slice. That boundary is role-based access control, and getting it wrong means showing one family another family's private information.

Role-based access control (RBAC) is the pattern of grouping permissions into roles and checking those permissions at every layer of the app: the UI hides what a role cannot use, the router blocks routes a role cannot open, and the server rejects requests a role cannot make. This guide shows how to build that in Flutter, using the same layering I used in Muntazim, where I implemented secure authentication and role-based access for parents. You can see the finished app in the Muntazim case study.

What is role-based access control in Flutter?

Role-based access control in Flutter is a way of deciding what each user can see and do by assigning them a role, such as parent, teacher or admin, and attaching a fixed set of permissions to each role. A permission is a single capability, like viewing a child's grades, recording attendance, sending an announcement or managing fee payments, and a role is a named bundle of those permissions. The app checks permissions, not roles, wherever a decision is made: a button asks whether the user can edit grades, not whether the user is a teacher. That distinction matters because roles change, a teacher can also be a parent, while permissions stay stable. Checking roles directly scatters hard-coded role names through the codebase and breaks the moment someone holds two roles. Checking permissions keeps every decision in one place: the role-to-permission map. The rest of this guide builds that map and enforces it in the UI, the router and the server.

In the school app used as the running example here, the roles break down like this:

Role	Can do
Parent	View own child's attendance, grades and fees; receive announcements
Teacher	View own classes; record attendance; enter grades; send class announcements
Admin	Manage users and fees; send school-wide announcements; view all records

Model roles and permissions as data

Start by modelling roles and permissions as plain Dart data, before any widget or route checks them. Two enums carry the whole system: AppRole for the roles and Permission for the capabilities. A single map connects them, and it is the only place in the app that knows which role can do what. The user model holds a list of roles, not a single role, and exposes a can() method so every check reads the same way:

\`dart
enum AppRole { parent, teacher, admin }

enum Permission {
viewOwnChild,
viewClass,
recordAttendance,
editGrades,
sendAnnouncement,
manageFees,
manageUsers,
}

const Map> rolePermissions = {
AppRole.parent: {
Permission.viewOwnChild,
},
AppRole.teacher: {
Permission.viewClass,
Permission.recordAttendance,
Permission.editGrades,
Permission.sendAnnouncement,
},
AppRole.admin: {
Permission.viewClass,
Permission.recordAttendance,
Permission.editGrades,
Permission.sendAnnouncement,
Permission.manageFees,
Permission.manageUsers,
},
};

class AppUser {
const AppUser({required this.id, required this.roles});

final String id;
final List roles;

Set get permissions =>
roles.expand((role) => rolePermissions[role] ?? {}).toSet();

bool can(Permission permission) => permissions.contains(permission);
}
`\

A parent who is also a teacher gets the union of both roles' permissions, with no special-casing anywhere else. When the school adds a role, you add one enum value and one map entry, and every screen, route and server rule picks it up. If you are setting up sign-in first, the Flutter Firebase authentication guide covers email, Google and phone auth end to end.

Gate the UI by role, but never trust the UI alone

The UI is where role checks are most visible, and it is also the layer where they matter least for security. Hiding a button stops an honest user from tapping it; it does nothing against a modified client or a direct API call. Gate the UI anyway, because a parent who never sees the fee-management screen cannot tap it by accident, and the interface stays clean for every role. Just treat UI gating as usability, not security, and enforce the same permission again on the server.

Keep the current user in a small session object, provided through Provider, with one can() method that the whole widget tree shares:

\`dart
class UserSession extends ChangeNotifier {
AppUser? _user;

AppUser? get user => _user;
bool get isSignedIn => _user != null;
bool can(Permission permission) => _user?.can(permission) ?? false;

void signIn(AppUser user) {
_user = user;
notifyListeners();
}

void updateUser(AppUser user) {
_user = user;
notifyListeners();
}

void signOut() {
_user = null;
notifyListeners();
}
}
`\

Then wrap role-restricted UI in a tiny RoleGate widget instead of scattering if statements through every screen:

\`dart
class RoleGate extends StatelessWidget {
const RoleGate({
super.key,
required this.permission,
required this.child,
this.fallback = const SizedBox.shrink(),
});

final Permission permission;
final Widget child;
final Widget fallback;

@override
Widget build(BuildContext context) {
final session = context.watch();
return session.can(permission) ? child : fallback;
}
}
`\

Usage reads plainly at the call site:

\dart RoleGate( permission: Permission.manageFees, child: ElevatedButton( onPressed: _openFeeManagement, child: const Text('Manage fees'), ), ) \\

One judgement call remains: hide or disable. Hide actions a role will never have, and disable with a short explanation the actions a role might gain later, so users understand the boundary instead of wondering where the button went.

Protect routes with go_router redirects

UI gating hides buttons, but a user can still reach a screen through a deep link, a bookmarked route or a typed URL on Flutter web. Route protection closes that gap: the router checks the permission before the page builds, and sends an unauthorized user somewhere safe. In go_router that check lives in the redirect callback, which runs on every navigation. Pass the session as refreshListenable so the redirect re-runs whenever the session changes, not just when the user navigates:

\`dart
final session = UserSession();

final router = GoRouter(
refreshListenable: session,
redirect: (context, state) {
final location = state.matchedLocation;

if (!session.isSignedIn && location != '/sign-in') {
  return '/sign-in';
}
if (location.startsWith('/admin') &&
    !session.can(Permission.manageUsers)) {
  return '/home';
}
if (location.startsWith('/fees') &&
    !session.can(Permission.manageFees)) {
  return '/home';
}
return null;

},
routes: [
GoRoute(
path: '/home',
builder: (context, state) => const HomeScreen(),
),
GoRoute(
path: '/fees',
builder: (context, state) => const FeesScreen(),
),
GoRoute(
path: '/admin',
builder: (context, state) => const AdminScreen(),
),
],
);
`\

Returning null lets the navigation proceed; returning a path reroutes the user. Keep the redirect purely about access, not loading data or showing dialogs, because it runs often and must stay fast. Provide the same session instance to the widget tree with ChangeNotifierProvider.value, so the router and the UI always agree about who the user is. For the full navigation setup, see the go_router guide.

Enforce every rule on the server

Everything above runs on the user's device, which means a determined user can bypass it. The server is the only layer you control, so it is the only layer that can say no. Every request that reads or writes protected data must be checked against the caller's roles on the server, using the same role-to-permission map. The client checks exist for a good experience; the server checks exist for security. With Firestore, that means security rules that mirror the client map, including a parent rule that only matches their own child's document:

\`
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
function roles() {
return get(/databases/$(database)/documents/users/$(request.auth.uid))
.data.roles;
}

function hasRole(role) {
  return request.auth != null && role in roles();
}

match /students/{studentId} {
  allow read: if hasRole('admin')
    || hasRole('teacher')
    || request.auth.uid in resource.data.parentIds;
  allow write: if hasRole('admin') || hasRole('teacher');
}

match /users/{userId} {
  allow read: if request.auth.uid == userId || hasRole('admin');
  allow update: if hasRole('admin');
}

}
}
`\

The users rule matters as much as the students rule: roles live in the user document, so if users can edit their own document they can grant themselves admin and walk through every other rule. Only admins may write the roles field. The same principle applies to a REST backend like the one behind Muntazim: verify the auth token on the server, load the caller's roles from the database, and return 403 before touching any data. The client sends the token and the server decides:

\dart final token = await FirebaseAuth.instance.currentUser?.getIdToken(); final response = await http.get( Uri.parse('https://api.example.com/children/abc123/grades'), headers: {'Authorization': 'Bearer ' + (token ?? '')}, ); \\

If the token is missing or the role check fails, the server answers 401 or 403 and the client shows a clear message. Test the server rules with the Firebase emulator or a staging backend before shipping; a wrong rule in production either leaks data or locks out every parent at the school gate.

Handle role changes while the app is running

Roles are not permanent. A school promotes a teacher to admin, or removes a parent's access when a child leaves. If the app caches the roles from sign-in and never refreshes them, the old permissions stay live until the next login, which can be days. Stream the user document instead, and update the session on every snapshot, so a role change takes effect while the app is open:

\dart Stream<AppUser> watchUser(String userId) { return FirebaseFirestore.instance .collection('users') .doc(userId) .snapshots() .map((doc) { final data = doc.data() ?? {}; final roles = (data['roles'] as List? ?? []) .whereType<String>() .where((name) => AppRole.values.any((role) => role.name == name)) .map(AppRole.values.byName) .toList(); return AppUser(id: doc.id, roles: roles); }); } \\

Filter out unknown role strings before calling byName, because byName throws on a name it does not recognise, and one bad value should not crash the app. Subscribe in the session, calling updateUser on each snapshot, and the router's refreshListenable does the rest: a demoted admin is redirected out of /admin the moment the snapshot arrives. Real-time updates flow through the same listeners in Muntazim, whether the payload is a role change or a school announcement; the Firebase push notifications guide covers the notification side in detail.

Mistakes that break role-based access

Most role-based access failures come from the same few shortcuts, and each one has a boring fix:

Mistake	What happens	Fix
Checking roles instead of permissions	Users with two roles break, and role names spread through the code	Check Permission values from one role map
Gating only the UI	Hidden screens still open through deep links or direct API calls	Protect routes and enforce the same rule on the server
Letting users edit their own roles	Anyone grants themselves admin	Role fields are writable by admins only
Caching roles at sign-in forever	Revoked access stays live until the next login	Stream the user document and refresh the session
One role per user	A teacher who is also a parent needs two accounts	Store a list of roles and union the permissions

Putting it together in Muntazim

In Muntazim, these layers stack the same way. Parents sign in with secure authentication, the app loads their roles, the interface shows only their own child's attendance, grades and fees, routes outside their role redirect away, notifications keep them posted on announcements, and the backend re-checks every request. No single layer carries the security; the layers agree with each other, so a failure in one is caught by the next. Role-based access control is not a widget or a rule, it is the same permission check repeated at every boundary a user can cross.

If your app has more than one kind of user, add roles before the second user type ships. Retrofitting permissions across screens, routes and a backend costs far more than modelling them on day one.

Get in touch and let's talk about your project.

Originally published at uzairxdev.online

Working with Humanizor AI: Crafting the Perfect Message

Muhammad Uzair — Fri, 13 Nov 2026 03:02:54 +0000

Crafting the Perfect Message: Working Alongside Humanizor AI Assistants

The future of writing isn't about AI replacing humans; it's about humans and AI collaborating seamlessly. Content creators are increasingly turning to Humanizor AI assistants not to write for them, but to refine and elevate their own ideas.

A New Workflow

The modern writing workflow often looks like this:

Brainstorming: The human writer outlines the core concepts and emotional beats.
Drafting: An LLM generates a rough, structured draft.
Humanization: The Humanizor AI steps in to reshape the text, adjusting the flow, tone, and vocabulary to sound natural and engaging.
Final Polish: The human writer reviews and adds their final unique touch.

Why This Matters

This collaborative approach allows creators to produce high-quality content at scale while maintaining authenticity. The Humanizor AI acts as a sophisticated editor, ensuring the final product resonates with human readers on a deeper level. The most successful creators of tomorrow will be those who master this symbiotic relationship with AI.

Originally published at uzairxdev.online

Collaborative Travel Planner in Flutter

Muhammad Uzair — Fri, 13 Nov 2026 03:01:48 +0000

Planning a group trip usually means a spreadsheet for the itinerary, a group chat for decisions, and a notes app for the packing list — and none of them agree with each other. Someone books a flight the spreadsheet does not know about, the checklist lives on one person's phone, and the split expenses get settled weeks later from memory. That is the problem Turnie was built to solve: one collaborative app that centralizes itineraries, split expenses and packing checklists, so the whole group works from the same plan.

I built Turnie in Flutter with Firebase as the backend, and implemented real-time collaboration using Firestore. More than 5,000 trips have been planned with it. This guide walks through the patterns that make a shared trip planner work in Flutter: a data model built for multiple editors, real-time listeners instead of manual refreshes, conflict-safe checklists and expense splits, offline support, and security rules that keep each trip private to its members.

Model the trip as shared documents

A collaborative app starts with a data model that expects more than one writer. The natural shape in Firestore is one document per trip, with subcollections for the things that grow independently: itinerary days, checklist items and expenses. The trip document itself holds the fields every screen needs at a glance — the destination, the dates and the list of member user IDs:

\`dart
class Trip {
const Trip({
required this.id,
required this.name,
required this.destination,
required this.startDate,
required this.endDate,
this.memberIds = const [],
});

final String id;
final String name;
final String destination;
final DateTime startDate;
final DateTime endDate;
final List memberIds;

factory Trip.fromJson(String id, Map json) {
return Trip(
id: id,
name: json['name'] as String,
destination: json['destination'] as String,
startDate: (json['startDate'] as Timestamp).toDate(),
endDate: (json['endDate'] as Timestamp).toDate(),
memberIds: List.from(json['memberIds'] as List? ?? []),
);
}

Map toJson() => {
'name': name,
'destination': destination,
'startDate': Timestamp.fromDate(startDate),
'endDate': Timestamp.fromDate(endDate),
'memberIds': memberIds,
};
}
`\

Keep each checklist item and each expense as its own document in a subcollection, not as a list field on the trip. Two people editing the same list field overwrite each other; two people editing different documents never collide. That one decision removes most of the sync bugs a collaborative app can have.

Listen, do not fetch

The defining feature of a collaborative app is that changes appear without anyone pressing refresh. In Firestore that means listening to a query with snapshots()\ and rebuilding the UI from the stream, instead of calling get()\ once and showing a stale copy:

\dart Stream<List<Trip>> watchTrips(String userId) { return FirebaseFirestore.instance .collection('trips') .where('memberIds', arrayContains: userId) .orderBy('startDate') .snapshots() .map((snapshot) => snapshot.docs .map((doc) => Trip.fromJson(doc.id, doc.data())) .toList()); } \\

Wire that stream into a StreamBuilder\ and the screen updates the moment a travel companion adds a flight or checks off a bag. Two details matter. First, show pending writes: snapshot.metadata.hasPendingWrites\ tells you the device has local changes the server has not confirmed yet, so you can dim or badge them instead of pretending they are saved. Second, handle the error branch of the stream — a permission denial or a lost connection should show a clear message, not a spinner that never stops.

Make shared checklists conflict-safe

A packing checklist is the feature where two people tap at the same time, and the naive implementation loses one of the taps. If the checklist is a single array on the trip document, each phone reads the array, flips one item and writes the whole array back — the second write silently erases the first. The fix is to store every checklist item as its own document and toggle it with a single-field update:

\dart Future<void> toggleChecklistItem({ required String tripId, required String itemId, required bool packed, }) { return FirebaseFirestore.instance .collection('trips') .doc(tripId) .collection('checklist') .doc(itemId) .update({'packed': packed, 'packedBy': currentUserId}); } \\

A single-field update touches only that field, so two people packing different items never conflict, and even two people toggling the same item resolve to the last write — which is the correct answer for a checkbox. Adding items is just as safe: each new item is a new document with an auto-generated ID, so two people adding at the same moment create two items instead of overwriting one.

Split expenses with transactions

Split expenses are the one place where last-write-wins is not good enough. If two people add expenses at the same time and both read the running total, add their amount and write it back, one expense disappears from the total. Firestore transactions solve this: the transaction re-reads the document and retries if it changed underneath you:

\`dart
Future addExpense({
required String tripId,
required Expense expense,
}) async {
final db = FirebaseFirestore.instance;
final tripRef = db.collection('trips').doc(tripId);

await db.runTransaction((transaction) async {
final tripSnap = await transaction.get(tripRef);
final currentTotal = (tripSnap.data()?['totalSpent'] as num?) ?? 0;

transaction.set(tripRef.collection('expenses').doc(), expense.toJson());
transaction.update(tripRef, {
  'totalSpent': currentTotal + expense.amount,
});

});
}
`\

Even simpler, when all you need is a running total, FieldValue.increment()\ applies the change on the server without reading first:

\dart tripRef.update({'totalSpent': FieldValue.increment(expense.amount)}); \\

Use the transaction when the write depends on the current value in a way increment cannot express — for example, capping the total or splitting by shares — and use FieldValue.increment()\ everywhere else. Either way, never compute a shared total on the client from a value you read seconds ago.

Keep it working offline

A travel app is used in airports, on planes and in places with no signal, so offline behaviour is a feature, not an edge case. Firestore on Android and iOS persists its cache and queues writes by default, which means the app keeps working without a connection: listeners keep serving cached data, writes queue locally, and everything syncs when the connection returns.

Design the UI around that reality. Show a small "offline — changes will sync" state when the device has no connection, and use snapshot.metadata.hasPendingWrites\ to mark queued items. Avoid patterns that break offline: do not require a server round trip before showing a screen, and do not treat a failed write as lost data when it may simply be queued. The same offline-first thinking applies to other apps too, and the full pattern is covered in the guide to privacy-first offline apps.

Lock each trip to its members

A shared trip is also a private trip: the itinerary, the expenses and the packing list belong to the members and nobody else. Firestore security rules enforce that on the server, so a client bug can never leak another group's trip:

\`
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /trips/{tripId} {
allow read, write: if request.auth != null
&& request.auth.uid in resource.data.memberIds;

  match /{subcollection}/{docId} {
    allow read, write: if request.auth != null
      && request.auth.uid in get(/databases/$(database)/documents/trips/$(tripId)).data.memberIds;
  }
}

}
}
`\

Note the rule for adding a member: the new member is not in memberIds\ yet, so the invite itself has to be handled by a trusted path — a Cloud Function or a dedicated invites collection with its own rules — rather than a direct write from the invited user. The setup for the auth side of this is covered in the Firebase authentication guide.

Test the sync with two devices

Real-time features cannot be tested on one emulator. Run the app on two devices or emulators signed in as two different members of the same trip, then exercise the cases that break naive implementations: toggle the same checklist item on both at once, add two expenses simultaneously, and kill the network on one device, make edits, and reconnect. Watch for the failure modes this article was designed around: a toggle that reverts, a total that drops an expense, or a screen that goes blank offline.

Keep the data layer behind a repository so the screens never talk to Firestore directly. That separation is what lets you test the sync logic with fake streams in widget tests, and it is the same pattern described in the guide to the repository pattern.

Putting it together

A collaborative travel planner is not a harder app to build than a single-user one — it is a different set of defaults. Model shared things as documents, not list fields. Listen instead of fetching. Update single fields instead of whole objects. Use transactions or server-side increments for shared totals. Let the offline cache do its job, lock each trip to its members with security rules, and test everything with two devices before you ship.

That is how Turnie works: one shared plan for the whole group, with itineraries, split expenses and packing checklists that stay in sync wherever the trip takes you. You can see the app in the Turnie case study.

Get in touch and let's talk about your project.

Originally published at uzairxdev.online

Synthesis: How AI Humanizors Are Passing the Turing Test

Muhammad Uzair — Thu, 12 Nov 2026 03:01:26 +0000

Synthesis: How AI Humanizors Are Passing the Turing Test

The Turing Test, proposed by Alan Turing in 1950, has long been the gold standard for measuring artificial intelligence. If a machine can converse with a human without being detected as a machine, it passes. Today, with the advent of sophisticated AI humanizors, this is no longer a hypothetical scenario—it's a daily occurrence.

The Role of AI Humanizors

Standard language models prioritize safety, neutrality, and factual accuracy. This results in a distinct "AI voice" that is easily detectable. AI humanizors counteract this by deliberately introducing:

Conversational Asymmetry: Real humans don't always answer questions directly; they tangent, they pause, they reflect. Humanizors simulate this cognitive meandering.
Contextual Imperfection: Slight structural irregularities make text feel grounded and less "plastic."
Deep Personalization: Adapting tone to match specific demographics or individual personas.

The Ethical Implications

As AI text becomes indistinguishable from human writing, we face new challenges. How do we verify authenticity? What does this mean for academic integrity, journalism, and personal communication? The technology is here, and the conversation around how to use it responsibly is just beginning.

Originally published at uzairxdev.online

Build a Period Tracker App in Flutter

Muhammad Uzair — Thu, 12 Nov 2026 03:00:19 +0000

A period tracker looks simple on the surface: a calendar, a few logged dates, a prediction. Underneath it is one of the most demanding apps a Flutter developer can build. The dates have to be right — a wrong prediction erodes trust faster than any crash. The data is some of the most sensitive health information a person carries, so privacy cannot be an afterthought. And cycles are irregular by nature, so the math has to adapt instead of assuming a textbook 28-day cycle.

I built HerCycle, a privacy-first period tracker with a menstrual calendar, an irregular-cycle prediction algorithm, ovulation and fertile-window estimates, symptom and mood logging, and health reports — all stored on-device, account-free and fully offline, with a PIN and biometric app lock. This guide walks through building that kind of app in Flutter, with working Dart code.

Model cycle data as dates, not strings

Everything in a period tracker derives from dates: when periods started, how long cycles lasted, when the next one is due. Keep one entry per logged day, with the date normalized to midnight and stored as an ISO 8601 string. It survives app restarts, database migrations and time zone changes without ambiguity, and DateTime.parse reads it back exactly.

Model each day as an immutable class with fromJson and toJson, so the storage layer stays boring and the logic layer works with real DateTime values:

enum FlowLevel { light, medium, heavy, spotting }
enum Mood { great, okay, low, irritable }

class DayEntry {
  const DayEntry({
    required this.date,
    this.flow,
    this.symptoms = const [],
    this.mood,
  });

  final DateTime date; // always normalized to midnight
  final FlowLevel? flow;
  final List<String> symptoms;
  final Mood? mood;

  factory DayEntry.fromJson(Map<String, dynamic> json) {
    return DayEntry(
      date: DateTime.parse(json['date'] as String),
      flow: json['flow'] == null
          ? null
          : FlowLevel.values.byName(json['flow'] as String),
      symptoms: List<String>.from(json['symptoms'] as List? ?? []),
      mood: json['mood'] == null
          ? null
          : Mood.values.byName(json['mood'] as String),
    );
  }

  Map<String, dynamic> toJson() => {
        'date': date.toIso8601String(),
        'flow': flow?.name,
        'symptoms': symptoms,
        'mood': mood?.name,
      };
}

Normalizing to midnight is the detail that saves you from the classic bug in this kind of app: two DateTime values for the same calendar day that are not equal because one carries a time component. Strip the time the moment a date enters the app, and run every comparison, set lookup and difference calculation through normalized dates:

DateTime normalizeDay(DateTime date) =>
    DateTime(date.year, date.month, date.day);

If you only remember one rule from this article, remember this one.

Compute cycle length from real history

A cycle length is the number of days between two consecutive period start dates. Deriving it from logged data — rather than asking the user to type in a number — is what makes the app feel smart and keeps the predictions honest. Given a list of period starts, the lengths are the gaps between neighbours:

List<int> cycleLengths(List<DateTime> periodStarts) {
  final sorted = List<DateTime>.of(periodStarts)..sort();
  final lengths = <int>[];
  for (var i = 1; i < sorted.length; i++) {
    lengths.add(sorted[i].difference(sorted[i - 1]).inDays);
  }
  return lengths;
}

Two edge cases matter. A brand-new user has no history, so there is nothing to average — the app must say so plainly and ask for at least two logged periods before predicting anything, instead of inventing a number. And a user can log a start date by mistake, so validate input: reject future dates and reject a start date inside an already logged period. Bad data in means wrong predictions out, and the user will blame the algorithm, not the typo.

Predict the next period, and handle irregular cycles

The naive prediction adds a fixed 28 days to the last period start. That is wrong for most people, most of the time. Real cycles vary, and a tracker that assumes regularity will be confidently wrong again and again. HerCycle predicts periods with an irregular-cycle algorithm that adapts to cycle variations, and the simplest robust version of that idea is the median of recent cycle lengths: it ignores outliers, so one unusually short or long cycle does not drag the prediction with it.

DateTime? predictNextPeriod(List<DateTime> periodStarts) {
  final lengths = cycleLengths(periodStarts);
  if (lengths.isEmpty) return null;

  final recent = lengths.length > 6
      ? lengths.sublist(lengths.length - 6)
      : lengths;
  recent.sort();
  final median = recent.length.isOdd
      ? recent[recent.length ~/ 2]
      : (recent[recent.length ~/ 2 - 1] + recent[recent.length ~/ 2]) ~/ 2;

  final lastStart = periodStarts.reduce(
    (a, b) => a.isAfter(b) ? a : b,
  );
  return normalizeDay(lastStart).add(Duration(days: median));
}

Using only the last six cycles keeps the prediction responsive to recent change. Present the result as a predicted window, not a promise: "expected around 22 December" holds up far better than a countdown that claims certainty it does not have. Predictions are estimates, and the app should say so, with a clear medical disclaimer that estimates are not medical advice.

Estimate ovulation and the fertile window

Once the next period is predicted, ovulation and the fertile window follow from it. The common estimation rule is that ovulation happens roughly 14 days before the next period starts, and the fertile window covers the five days before ovulation plus ovulation day itself. It is an estimate built on an estimate, so it inherits all of the uncertainty of the period prediction — another reason to show a range rather than a single day.

({DateTime ovulation, DateTime fertileStart, DateTime fertileEnd})
    fertileWindow(DateTime predictedNextPeriod) {
  final ovulation = predictedNextPeriod.subtract(const Duration(days: 14));
  return (
    ovulation: ovulation,
    fertileStart: ovulation.subtract(const Duration(days: 5)),
    fertileEnd: ovulation,
  );
}

HerCycle refines these estimates with optional inputs: basal body temperature, cervical mucus observations, and a pregnancy due date. Each is a separate, optional signal the user can add when they have it and ignore when they do not — never require data the user may not have, and never let a missing input break the core flow.

Build the calendar UI

The calendar is the home screen of a period tracker, and it has one job: make the state of the cycle readable at a glance. Colour-code each day by its type — logged period days, the predicted next period, the fertile window, ovulation day, and today — and keep the legend to four or five colours at most. A calendar with twelve shades of pink communicates nothing.

Derive the colour from a pure function that maps a date to a day type, so the UI stays dumb and the logic stays testable:

enum DayType { period, predictedPeriod, fertile, ovulation, none }

DayType dayType(
  DateTime day, {
  required Set<DateTime> loggedPeriodDays,
  required DateTime? predictedStart,
  required DateTime? fertileStart,
  required DateTime? fertileEnd,
  required DateTime? ovulation,
}) {
  final d = normalizeDay(day);
  if (loggedPeriodDays.contains(d)) return DayType.period;
  if (predictedStart != null && d == normalizeDay(predictedStart)) {
    return DayType.predictedPeriod;
  }
  if (ovulation != null && d == normalizeDay(ovulation)) {
    return DayType.ovulation;
  }
  if (fertileStart != null && fertileEnd != null) {
    final start = normalizeDay(fertileStart);
    final end = normalizeDay(fertileEnd);
    if (!d.isBefore(start) && !d.isAfter(end)) return DayType.fertile;
  }
  return DayType.none;
}

Two details make this work. The set of logged period days must contain normalized dates, or contains will miss days that are actually logged. And the order of the checks is the priority order: a logged period day beats a prediction, and ovulation beats the fertile window it sits inside. Add a next-period countdown chip above the calendar — "next period in 6 days" is the single most checked number in the app.

Log symptoms, mood and flow, then turn them into a report

Logging is where a tracker earns its keep between periods. HerCycle logs symptoms, PMS and mood alongside flow, and turns that history into cycle health reports users can share with their doctor. The logging UI should be fast: one tap per symptom, a small set of mood options, a flow selector — because nobody will fill in a form every day, but many people will tap three chips.

Store the entries keyed by normalized date so each day holds at most one entry, and build the report from the same data the calendar already uses: recent cycle lengths and their variation, average flow days, the most frequently logged symptoms, and the mood trend across the cycle. Generate the report as a plain summary the user can share from the app — the numbers that help a doctor are the recent history, not a lifetime of raw data. The same on-device patterns apply to a health vitals tracker too.

Remind without a server

A tracker that never reminds is a tracker the user forgets to open. The reminder for a predicted period belongs on the device, scheduled locally — there is no reason to involve a server, and every reason not to. Use flutter_local_notifications with timezone-aware scheduling, and schedule the reminder a day before the predicted start:

Future<void> schedulePeriodReminder(DateTime predictedStart) async {
  final reminderDay = predictedStart.subtract(const Duration(days: 1));
  await flutterLocalNotificationsPlugin.zonedSchedule(
    100,
    'Period expected tomorrow',
    'Your next period is predicted to start tomorrow.',
    tz.TZDateTime.from(reminderDay, tz.local),
    const NotificationDetails(
      android: AndroidNotificationDetails('cycle', 'Cycle reminders'),
    ),
    androidScheduleMode: AndroidScheduleMode.exactAllowWhileIdle,
    uiLocalNotificationDateInterpretation:
        UILocalNotificationDateInterpretation.absoluteTime,
  );
}

Reschedule reminders whenever the prediction changes — a newly logged period moves everything, so cancel the old notification and schedule a fresh one in the same step. The full setup, including the timezone package and the Android exact-alarm permission, is covered in the local notifications guide.

Privacy is the architecture, not a setting

This is the section that decides whether people trust the app. Cycle data is intimate health data, and the only privacy promise that holds up is a structural one: everything is stored on-device, there is no account, no registration, and no server sync. HerCycle works fully offline for exactly this reason, and that architecture is not a marketing line — it is the product. The full pattern is covered in the guide to privacy-first offline apps.

On-device storage only holds if the phone itself cannot be picked up and read by anyone else, which is why the app ships a PIN and biometric app lock. Gate the app behind local_auth before any cycle data renders:

final didAuthenticate = await LocalAuthentication().authenticate(
  localizedReason: 'Unlock HerCycle to view your cycle data',
  options: const AuthenticationOptions(biometricOnly: true),
);

If authentication fails or is unavailable, fall back to the PIN screen — never to an unlocked view. And keep the analytics honest: crash reporting that uploads device data by default quietly breaks the promise the app just made, so leave it out or make it opt-in.

Test the algorithm with fixed dates

Date math is exactly the kind of code that looks right and is wrong, so test it with fixed dates. A small test file with known histories pins down the median and the empty-history case:

test('predicts the next period from the median cycle length', () {
  final starts = [
    DateTime(2026, 9, 1),
    DateTime(2026, 9, 29),
    DateTime(2026, 10, 28),
    DateTime(2026, 11, 24),
  ];
  expect(predictNextPeriod(starts), DateTime(2026, 12, 22));
});

test('returns null with fewer than two logged periods', () {
  expect(predictNextPeriod([DateTime(2026, 11, 1)]), isNull);
});

Check the first test by hand: the gaps are 28, 29 and 27 days, so the median is 28, and 24 November plus 28 days is 22 December. Add a test with one wildly irregular cycle — a 45-day gap among 28-day cycles — and confirm the median ignores it while a plain average would not. That test is the whole argument for the median in one assertion.

Putting it together

A period tracker is a small set of well-separated pieces: a date model normalized to midnight, cycle lengths derived from logged history, a median-based prediction that adapts to irregular cycles, an ovulation and fertile-window estimate built on that prediction, a calendar that renders a pure day-type function, fast per-day logging that feeds a shareable health report, local reminders, and on-device storage behind a PIN or biometric lock. Each piece is easy to test on its own, and none of them needs a backend.

Get in touch and let's talk about your project.

Originally published at uzairxdev.online

From Senior Engineer to Tech Lead: Skills You Need

Muhammad Uzair — Wed, 11 Nov 2026 03:01:00 +0000

From Senior Engineer to Tech Lead: The Skills Code Doesn't Teach You

For the first five to eight years of a software engineer's career, the measure of success is straightforward: How much high-quality code can you ship?

You master design patterns, commit thousands of lines of well-tested code, optimize build pipelines, and squash edge-case bugs. You feel unstoppable.

Then, you receive the promotion: Tech Lead.

Suddenly, the skills that got you here are no longer sufficient. If you attempt to lead by simply writing twice as much code, you will quickly burn out, create bottlenecks, and disempower your teammates.

Here is what the transition from Senior Engineer to Tech Lead actually requires, and how to become a genuine force multiplier.

1. Escaping the "Individual Contributor Trap"

The most difficult psychological shift for a new Tech Lead is stepping back from the keyboard.

As a Senior Engineer, your contribution is linear:
\Your Output = Your Hours × Your Technical Skill \\

As a Tech Lead, your contribution must be multiplicative:
\Your Output = Team Velocity × Architectural Clarity × Unblocked Decisions \\

If you assign yourself the most critical, complex architectural feature on the critical path, you become the team's single point of failure. While you are heads-down coding for six hours, three other developers are blocked waiting for code reviews, requirements clarification, or API contracts.

The Golden Rule: The Tech Lead's primary job is not to write all the code, but to ensure that the best code gets written.

2. Architectural Stewardship & Technical Design Documents (RFCs)

A Tech Lead sets the technical direction without dictating every line. The primary tool for this is the RFC (Request for Comments) / Technical Design Document.

Before kicking off a multi-sprint initiative, write a concise 2-to-3 page design doc covering:

The Problem Statement: What business or user pain are we solving?
Non-Goals: What are we explicitly not building in this iteration?
Proposed Architecture: System diagrams, data contracts, state management patterns.
Considered Alternatives & Tradeoffs: Why did we choose Approach A over Approach B?
Failure Modes & Migration Strategy: How does the system degrade gracefully when things break?

Circulate the document among your team. Encourage junior and mid-level engineers to challenge assumptions. When the team collaboratively reviews the blueprint before writing code, implementation velocity accelerates dramatically.

3. Defending Developer Flow

A major source of engineering friction is context switching: spontaneous meetings, vague ticket specifications, and shifting priorities.

As a Tech Lead, you are the buffer between external business turbulence and your team's focus time:

Partner closely with your Product Manager to ensure user stories meet the "Definition of Ready" before sprint kickoff.
Aggressively decline unnecessary meetings on behalf of your team. Protect long, uninterrupted blocks of maker time.
Translate ambiguous business requirements into precise, actionable technical tasks.

4. Cultivating Psychological Safety & Blameless Culture

High-performing teams are not teams that never experience bugs; they are teams that learn exponentially from failures without fear.

When a critical production bug slips through:

Never ask: "Who wrote this code?"
Always ask: "What gap in our automated test suite, CI/CD pipeline, or review process allowed this regression to reach production?"

Lead Blameless Postmortems. Document the incident timeline, the root cause, the immediate mitigation, and the preventive action items. When engineers know they won't be penalized for honest mistakes, they build with greater confidence, innovate faster, and take ownership of systemic quality.

5. Mentorship as an Architectural Investment

The ultimate test of a Tech Lead's efficacy is simple:

If you take a two-week vacation completely off the grid, does the engineering team continue to ship features smoothly without you?

If the answer is no, you haven't built a team—you have built a dependency on yourself.

Invest proactively in your team:

Pair Programming: Don't just point out flaws in pull requests; jump on a 20-minute pairing session to demonstrate problem-solving workflows.
Strategic Delegation: Give challenging architectural modules to mid-level engineers with your guidance, rather than hoarding the fun work for yourself.
Constructive PR Reviews: Frame feedback as inquiries ("How does this handle low-memory scenarios?") rather than commands ("Change this").

The Transition Summary

Mindset	Senior Engineer	Tech Lead
Primary Focus	My code & my tickets	Team velocity & system health
Solving Problems	"I will fix it myself"	"I will empower the team to solve it"
Communication	Technical precision	Strategic empathy & business alignment
Success Metric	Features shipped by me	Capabilities unlocked across the team

Leading technical teams is challenging, but seeing an entire engineering team thrive, grow, and deliver exceptional products together is the most rewarding milestone in a software engineer's career.

Originally published at uzairxdev.online

Build a Quiz App in Flutter: Full Guide

Muhammad Uzair — Wed, 11 Nov 2026 02:59:48 +0000

Quiz apps are one of the most useful projects a Flutter developer can build. The pattern shows up everywhere: exam prep, language learning, driving theory, onboarding quizzes, and trivia games. Underneath the friendly interface, a quiz app is a compact engineering problem — a question bank, a fair way to pick and order questions, state that survives taps and rotations, scoring, and progress that persists between sessions.

I built the practice test engine for AI US Citizenship Test 2026, an app that prepares green card holders for the US naturalization interview. The app covers 100 civics questions, the English test, and the N-400 interview, with an AI tutor that explains answers in plain words, realistic mock interviews, and an audio study mode. The quiz engine at its core is the same one any quiz app needs, and this guide walks through building it from scratch with working Dart code.

Model the question bank first

Every quiz starts with data, not widgets. A question needs its text, a list of options, the index of the correct option, and an optional explanation shown after the user answers. Model it as an immutable class with a fromJson\ factory so the bank can live in a JSON file:

\`dart
class Question {
const Question({
required this.text,
required this.options,
required this.correctIndex,
this.explanation,
});

final String text;
final List options;
final int correctIndex;
final String? explanation;

factory Question.fromJson(Map json) {
return Question(
text: json['text'] as String,
options: List.from(json['options'] as List),
correctIndex: json['correctIndex'] as int,
explanation: json['explanation'] as String?,
);
}
}
`\

Keeping the bank in JSON has a practical advantage: content and code stay separate. A subject-matter expert can add questions without touching Dart, and the same file can feed a practice mode, a timed test, and a review screen. Validate the data on load — every question should have at least two options, and correctIndex\ must point at a real option. A single bad index crashes the scoring logic later, so fail loudly at load time instead of silently during a test.

Load the bank from an asset

Ship the questions as a JSON asset bundled with the app. That keeps the quiz working offline, which matters for a study app — users revise on the train, in waiting rooms, and anywhere else with no signal. Load it once when the quiz screen starts:

\dart Future<List<Question>> loadQuestions(String assetPath) async { final raw = await rootBundle.loadString(assetPath); final decoded = jsonDecode(raw) as List; return decoded .map((item) => Question.fromJson(item as Map<String, dynamic>)) .toList(); } \\

Register the file under assets:\ in pubspec.yaml\. For a large bank, split it by category or chapter into several files and load only the set the user picked. A civics bank with hundreds of questions loads fast either way, but a 10 MB JSON file parsed on the main isolate will drop frames — for very large banks, parse on a background isolate with compute\.

Shuffle fairly, and never repeat a question

A quiz that shows the same questions in the same order every time stops testing anything after the second run. Shuffle a copy of the bank, take the first N questions, and keep the original list untouched:

\dart List<Question> buildQuiz( List<Question> bank, { int count = 10, int? seed, }) { final questions = List<Question>.of(bank)..shuffle(Random(seed)); return questions.take(count).toList(); } \\

Two details matter here. First, copy before shuffling: List.of(bank)\ creates a new list, so the bank keeps its original order for the review screen and for the next session. Second, shuffle once per quiz, not once per build. If the shuffle lives inside build()\, every rebuild reorders the questions under the user's finger. Do it in initState\ or in the controller that owns the quiz state.

Passing a seed makes a shuffle reproducible, which is handy for tests and for a mock interview mode where the teacher and the student need the same question order. In production, leave the seed out and let Random()\ draw from the system entropy source.

Hold quiz state in a small controller

A quiz has a clear lifecycle: ready, answering, finished. Encoding that as an enum keeps the UI honest — the results screen cannot appear while a question is still unanswered, and the answer buttons cannot be tapped after the quiz ends. A ChangeNotifier\ holds the current index, the answers map, and the score:

\`dart
enum QuizPhase { ready, answering, finished }

class QuizController extends ChangeNotifier {
QuizController(this.questions);

final List questions;
final Map answers = {};
int currentIndex = 0;
QuizPhase phase = QuizPhase.ready;

Question get current => questions[currentIndex];

void answer(int optionIndex) {
answers[currentIndex] = optionIndex;
notifyListeners();
}

void next() {
if (currentIndex < questions.length - 1) {
currentIndex++;
} else {
phase = QuizPhase.finished;
}
notifyListeners();
}

int get score => answers.entries
.where((entry) => questions[entry.key].correctIndex == entry.value)
.length;
}
`\

Store answers as a map from question index to chosen option index, not as a list of booleans. The map makes the review screen trivial: iterate the questions, look up each answer, and show the correct option next to the one the user picked. It also lets the user go back and change an answer before finishing, which a boolean list cannot express.

Expose the controller with a ChangeNotifierProvider\ above the quiz screen. Widgets that only show the question text can listen to it; the progress bar and the score display rebuild when the state changes, and nothing else does.

Score at the end, not during the run

Score the quiz when it finishes, from the answers map, instead of incrementing a counter on every tap. The two approaches agree when everything works, but the derived score stays correct when a user changes an answer, when a question is skipped, and when the app restores a half-finished session. Derived state cannot drift out of sync with its source.

Show the result as more than a number. A pass mark — for example, 6 out of 10 — tells the user whether they are ready, and a per-question review tells them what to study next. Include the explanation from the question model on the review screen: a wrong answer without an explanation is a missed teaching moment, and for a test-prep app the explanation is the product. In the citizenship app, the AI tutor takes this further and explains civics answers in plain words when the short explanation is not enough.

Save progress on the device

Users abandon a quiz halfway and come back the next day. Save the best score and the last completed set with shared_preferences\, and only write when the new score beats the stored one:

\dart Future<void> saveBestScore(int score) async { final prefs = await SharedPreferences.getInstance(); final best = prefs.getInt('best_score') ?? 0; if (score > best) { await prefs.setInt('best_score', score); } } \\

For richer state — the answers of an unfinished quiz, a streak of study days, per-category scores — use a local database such as Drift or Isar instead of piling keys into preferences. The rule of thumb: preferences for a handful of settings and best scores, a database for anything shaped like a table.

Keep everything on-device unless the app genuinely needs an account. The citizenship app stores practice progress locally, and the same approach fits most quiz apps: no login wall, no sync conflicts, and the quiz works the moment the app opens. If you later add cloud backup, make it opt-in and sync only after the local write succeeds.

Add a per-question timer for exam mode

A practice mode can be untimed, but a mock exam needs a clock. A Timer.periodic\ ticks once a second, and when it reaches zero the question counts as unanswered and the quiz moves on:

\`dart
Timer? _timer;
int secondsLeft = 30;

void _startTimer() {
_timer?.cancel();
secondsLeft = 30;
_timer = Timer.periodic(const Duration(seconds: 1), (timer) {
secondsLeft--;
if (secondsLeft <= 0) {
timer.cancel();
next(); // Unanswered counts as wrong.
}
notifyListeners();
});
}
`\

Cancel the timer in dispose\ and restart it on every next()\. A timer that keeps firing after the screen is gone leaks, and a timer that is not restarted gives the second question the first question's remaining seconds. Show the countdown as a thin progress bar above the question — a number alone is easy to miss, and a shrinking bar communicates urgency without stealing attention.

Mistakes to avoid

The most common bug in a first quiz app is shuffling inside build()\, which reorders the questions on every rebuild. The second is storing the selected answer in the widget's local state instead of the controller: the selection vanishes on rotation or when the user navigates to the review screen and back. The third is scoring by incrementing a counter in the tap handler, which breaks the moment an answer can change.

A subtler one is loading the question bank on every screen. Load it once, pass the list down, and keep a single source of truth. And validate the bank at startup in debug mode with an assert: every question needs at least two options, a valid correctIndex\, and a non-empty question text. Bad content is far cheaper to catch in development than in a user's test session.

Putting it together

A quiz app is a small set of well-separated pieces: a question model and a JSON bank, a shuffle that runs once, a controller holding an explicit phase and an answers map, a score derived from that map, local persistence for progress, and an optional timer for exam mode. Each piece is easy to test on its own, and none of them needs a backend.

Start with ten questions in a single JSON file and the controller above. Add categories, review screens, and timed mock exams one at a time, testing each against the real question bank. The same structure scales from a trivia game to a serious exam-prep tool — the citizenship app's practice test engine, mock interviews, and audio study mode all sit on top of this exact foundation. If you want to round out the experience, pair the quiz with ZIP-code autofill for location-specific questions, offline audio playback for a study mode that works without a connection, and local notifications for daily study reminders.

Get in touch and let's talk about your project.

Originally published at uzairxdev.online

Production Mobile Security: Hardening Apps Against Attacks

Muhammad Uzair — Tue, 10 Nov 2026 03:01:52 +0000

Production Mobile Security: Hardening Cross-Platform Apps Against Reverse Engineering

When developers transition from web backend engineering to mobile app development, they frequently carry a dangerous assumption: that client-side code executes in a trusted, controlled environment.

On mobile devices, this assumption is completely false.

Your APK or IPA binary lives entirely on the user's hardware. Anyone with basic tools like apktool\, jadx\, ghidra\, or an HTTP proxy like Charles or Proxyman can unpack your binary, inspect your strings, intercept your network traffic, and manipulate runtime memory using dynamic instrumentation frameworks like Frida.

Here is an architectural guide to hardening cross-platform mobile applications against real-world vulnerabilities.

1. Threat Modeling the Mobile Client

Before writing security code, understand what an attacker can easily do to an unhardened app:

Static Analysis: Decompiling the application package to find hardcoded API secrets, private endpoints, or insecure encryption keys.
Man-In-The-Middle (MITM) Attacks: Installing a custom Root CA certificate on an emulator or rooted device to inspect and alter HTTPS payloads.
Dynamic Hooking (Frida/Objection): Overriding Dart or native C++ method return values at runtime (e.g., forcing isUserAuthenticated()\ to always return true\).
Data-at-Rest Extraction: Pulling unencrypted databases, token caches, and session identifiers from local application sandboxes.

2. Cryptographic Storage: Zero Plaintext on Disk

Never store sensitive credentials, session tokens, or PII (Personally Identifiable Information) in standard storage mechanisms like Android's SharedPreferences\ or iOS's NSUserDefaults\. These files are plain XML and plist files that can be read with a single adb command.

The Solution:

Use hardware-backed security modules:

Android: Uses the Android Keystore system with AES-256 GCM encryption.
iOS: Uses the Secure Enclave and iOS Keychain.

In Flutter, leverage flutter_secure_storage\ configured with strict hardware security options:

\`dart
import 'package:flutter_secure_storage/flutter_secure_storage.dart';

const secureStorage = FlutterSecureStorage(
aOptions: AndroidOptions(
encryptedSharedPreferences: true,
keyCipherAlgorithm: KeyCipherAlgorithm.RSA_ECB_PKCS1Padding,
storageCipherAlgorithm: StorageCipherAlgorithm.AES_GCM_NoPadding,
),
iOptions: IOSOptions(
accessibility: KeychainAccessibility.first_unlock,
synchronizable: false,
),
);
`\

For local databases (Drift / SQLite), always encrypt the entire database file using SQLCipher with a 256-bit key dynamically derived from the hardware Keystore.

3. Network Hardening: Enforcing SSL/TLS Pinning

By default, an app trusts any certificate signed by a Certificate Authority installed in the device's system trust store. If a user installs a custom proxy certificate, they can read every API request in plaintext.

SSL Pinning forces the app to accept only known certificates or public keys specifically hardcoded into the app.

Best Practice: Public Key Pinning (SPKI)

Pin the SHA-256 hash of the server's Subject Public Key Info (SPKI) rather than the leaf certificate. When your leaf certificate renews annually, your public key remains unchanged, eliminating the risk of accidental app lockouts. Always provide at least one backup pin.

\`dart
// Example: SSL Pinning with Dio and SecurityContext
Dio createSecureDioClient() {
final dio = Dio();

final securityContext = SecurityContext(withTrustedRoots: false);
// Import your organization's trusted root / intermediate cert
securityContext.setTrustedCertificatesBytes(rawCertBytes);

final httpClient = HttpClient(context: securityContext);
httpClient.badCertificateCallback = (cert, host, port) {
// Strictly reject any certificate that fails validation
return false;
};

(dio.httpClientAdapter as IOHttpClientAdapter).createHttpClient = () => httpClient;
return dio;
}
`\

4. Binary Obfuscation and Symbol Stripping

When you build a release Flutter binary without flags, class names, field identifiers, and symbol tables remain largely readable in the compiled snapshot.

Enable full Dart symbol obfuscation during your release build pipeline:
\`bash
flutter build appbundle --release \
--obfuscate \
--split-debug-info=./build/symbols/android

flutter build ipa --release \
--obfuscate \
--split-debug-info=./build/symbols/ios
`\

This strips human-readable symbols from the output binary and generates a mapping file that you securely archive in your CI/CD storage to de-obfuscate production crash stack traces.

5. Runtime Integrity & Anti-Tampering

For high-stakes applications (banking, healthcare, fintech), client-side heuristics are insufficient. Implement server-verified attestation:

Google Play Integrity API (Android): Verifies that the app binary was installed through Google Play and that the device is running a genuine, certified Android build.
Apple App Attest (iOS): Uses the Secure Enclave to generate a cryptographic key pair that attests the authenticity of the app to your backend before issuing sensitive tokens.
Screen Privacy Protection: Prevent confidential data from leaking in the recent apps switcher:
- On Android, set FLAG_SECURE\ on the window to block screenshots and screen recording.
- On iOS, render a blurred visual overlay when applicationWillResignActive\ triggers.

The Golden Principle: The Backend is the Gatekeeper

No amount of client-side hardening makes a mobile device 100% impenetrable. A determined reverse engineer with physical access and a hardware debugger can eventually bypass client checks.

Therefore, never trust the client for business rules, authorization, or rate limiting. Treat mobile security hardening as defense-in-depth: raising the cost and complexity of attacks so high that malicious actors look elsewhere.

Originally published at uzairxdev.online

Flutter Isolates: Heavy Work Without Jank

Muhammad Uzair — Tue, 10 Nov 2026 03:00:46 +0000

Flutter apps feel fast until they do not. A scroll stutters, a button tap waits half a second, an animation drops frames — and the cause is rarely the widget tree. More often, the app is doing heavy work on the same thread that draws the UI. Dart runs your code on a single thread, called the main isolate, and while that thread is busy parsing JSON or crunching numbers, it cannot build frames. The fix is to move the heavy work somewhere else: a second isolate.

An isolate is Dart's version of a thread, with one important difference: isolates do not share memory. Each one has its own heap and its own event loop, so they communicate only by sending messages. That sounds restrictive, but it is exactly what makes them safe. There are no data races, no locks, and no shared mutable state to corrupt. You send a value in, you get a value back, and the UI thread keeps drawing frames in the meantime.

How much work is too much for the main isolate

Flutter targets 60 frames per second, which gives the main isolate about 16 milliseconds per frame. Any single task that takes longer than that risks a missed frame. Parsing a large JSON response, decoding a big image, sorting thousands of records, or running a compression routine can easily take 50 to 500 milliseconds. Users notice that as a freeze.

A useful rule: if the work takes more than a few milliseconds and you cannot break it into small chunks, move it to another isolate. If the work takes less than a millisecond, the cost of spawning an isolate and copying the data across is higher than just doing it inline. Measure first — the DevTools timeline shows long tasks on the UI thread clearly — then isolate the real offenders.

Isolate.run: the simplest option

Dart 2.19 introduced Isolate.run\, the easiest way to run a function on a background isolate. You pass it a function, it runs that function on a new isolate, and it returns a Future with the result:

\`dart
import 'dart:isolate';

Future> loadProducts(String rawJson) async {
// Parsing happens on a background isolate.
// The UI thread stays free to draw frames.
return Isolate.run(() => parseProducts(rawJson));
}

List parseProducts(String rawJson) {
final decoded = jsonDecode(rawJson) as List;
return decoded
.map((item) => Product.fromJson(item as Map))
.toList();
}
`\

A few details matter here. Isolate.run\ creates a new isolate, runs the function, sends the result back, and shuts the isolate down. That is perfect for one-off jobs such as parsing a network response or decoding a file. The function you pass must be a top-level function, a static method, or a closure that captures only values that can be sent between isolates. A closure that captures a BuildContext\, a controller, or any object holding native resources will fail at runtime, so keep the function self-contained and pass everything it needs as arguments.

The result must also be sendable. Plain data — numbers, strings, lists, maps, and objects made only of those — crosses the boundary fine. Objects that hold sockets, file handles, or platform channels do not, and the isolate will throw when you try to send them.

compute: the Flutter shortcut

Flutter ships a convenience wrapper called compute\ in package:flutter/foundation.dart\. It does the same job as Isolate.run\ for a single function call, and it is the form you will see most often in Flutter code:

\`dart
import 'package:flutter/foundation.dart';

Future> loadProducts(String rawJson) async {
return compute(parseProducts, rawJson);
}

// Must be a top-level or static function.
List parseProducts(String rawJson) {
final decoded = jsonDecode(rawJson) as List;
return decoded
.map((item) => Product.fromJson(item as Map))
.toList();
}
`\

compute\ takes the function and a single argument. If your function needs several inputs, wrap them in a record or a small data class and pass that as the one argument. Under the hood, compute\ spawns an isolate, runs the function, returns the result, and tears the isolate down — the same lifecycle as Isolate.run\, with a Flutter-friendly API. For one-off background work in a Flutter app, compute\ is usually the right default.

Isolate.spawn: when the work never stops

Isolate.run\ and compute\ are built for single jobs: spawn, run, return, shut down. Some work does not fit that shape. A background worker that processes a stream of images, a worker that keeps a connection open, or a long-running computation that reports progress all need an isolate that stays alive. That is what Isolate.spawn\ is for.

With Isolate.spawn\, you create the isolate yourself and talk to it through ports. A SendPort\ sends messages; a ReceivePort\ listens for them:

\`dart
import 'dart:isolate';

Future main() async {
final receivePort = ReceivePort();
await Isolate.spawn(_workerEntry, receivePort.sendPort);

// The worker sends its own SendPort back first.
final sendPort = await receivePort.first as SendPort;

// Ask the worker to do something.
sendPort.send('process this image');
}

void _workerEntry(SendPort mainSendPort) {
final workerPort = ReceivePort();
mainSendPort.send(workerPort.sendPort);

workerPort.listen((message) {
// Heavy work happens here, on the worker isolate.
final result = doHeavyWork(message as String);
mainSendPort.send(result);
});
}
`\

The handshake at the start is the pattern to remember: the spawned isolate creates its own ReceivePort\, sends that port's SendPort\ back to the main isolate, and from then on the two sides exchange messages. The worker isolate stays alive until you call isolate.kill()\ or it exits on its own, so remember to shut it down when the screen that owns it is disposed, or you will leak an isolate for the life of the app.

Isolate.spawn\ is more code than compute\, and that is the point: you only reach for it when a single-shot call is not enough. If you find yourself spawning an isolate for every tap, you are paying the spawn cost repeatedly for no benefit — use compute\ or keep one worker isolate alive instead.

What can cross the isolate boundary

Messages between isolates are copied, not shared. That has two consequences worth knowing. First, sending a large object costs time: a 10 MB list is serialized, copied, and deserialized on the other side. For very large payloads, that copy can eat the benefit of the background work, so prefer sending compact data — a file path instead of the file bytes, or an ID instead of a full object — and let the worker read what it needs itself.

Second, only certain values can be sent: null, numbers, booleans, strings, lists and maps of sendable values, SendPort\ instances, and objects whose fields are all sendable. Anything holding a native resource — a database connection, an open file, a platform channel, a BuildContext\ — cannot cross. If you get an error about an un-sendable object, the fix is almost always to move the creation of that resource inside the worker, or to pass a plain description of the work instead of the resource itself.

Common mistakes

Three mistakes show up again and again. The first is isolating work that is too small: spawning an isolate for a task that takes one millisecond costs more than it saves, and the app gets slower, not faster. The second is capturing UI objects in the background function — a closure that quietly holds a controller or a context will fail when the message is sent, often far from the line that caused it. The third is forgetting that isolates cannot touch the UI at all: there is no setState\ from a background isolate, no platform channel call, and no access to plugins that rely on the main isolate. The worker computes; the main isolate updates the screen with the result.

A complete example: parsing without the freeze

Putting it together, here is the pattern most apps end up with: fetch on the main isolate, parse on a background isolate, render when the result arrives.

\`dart
import 'package:flutter/foundation.dart';
import 'package:http/http.dart' as http;

class ProductListScreen extends StatefulWidget {
const ProductListScreen({super.key});

@override
State createState() => _ProductListScreenState();
}

class _ProductListScreenState extends State {
late final Future> _products;

@override
void initState() {
super.initState();
_products = _fetchProducts();
}

Future> _fetchProducts() async {
final response = await http.get(Uri.parse('https://api.example.com/products'));
// The expensive parse runs off the main isolate.
return compute(parseProducts, response.body);
}

@override
Widget build(BuildContext context) {
return FutureBuilder>(
future: _products,
builder: (context, snapshot) {
if (!snapshot.hasData) {
return const Center(child: CircularProgressIndicator());
}
final products = snapshot.data!;
return ListView.builder(
itemCount: products.length,
itemBuilder: (context, index) {
return ListTile(title: Text(products[index].name));
},
);
},
);
}
}
`\

Nothing about the UI changed. The fetch, the parse, and the list are the same as before — the only difference is that compute\ moves the parse to a background isolate, so the loading spinner animates smoothly while a large response is being decoded. That is the whole point of isolates: the user should never be able to tell that heavy work is happening at all.

If you want to go deeper into how Dart handles work that waits — network calls, timers, and streams — read Dart Streams vs Futures: When to Use Each. And if the heavy work in your app comes from an on-device AI model, the same off-thread thinking applies; see Flutter On-Device AI With TensorFlow Lite.

Isolates are not a performance trick. They are the way Dart is designed to handle heavy work: keep the main isolate free to draw frames, send plain data to a worker, and bring the result back. Start with compute\ for one-off jobs, reach for Isolate.spawn\ when the worker needs to stay alive, and measure before and after — the frame timeline in DevTools will show the difference immediately.

Get in touch and let's talk about your project.

Originally published at uzairxdev.online