Genuinely. You showed up for articles about Flutter architecture, mobile patterns, and the quiet frustrations of building mobile products that actually scale. That’s a specific kind of curiosity, and I don’t take it lightly.

Something has been in the works for a while now, and I wanted you, my Medium readers, to be among the first to hear about it.

Mobterest Studio has a new home.

All my writing, deep dives, and developer resources have moved to mobterest.studio , a space I actually own and control, built specifically for mobile engineers and Flutter developers.

It’s where I’ll be publishing from now on. New articles, architecture breakdowns, behind-the-scenes of what I’m building; all of it lives there.

You’re warmly invited to follow along.

And while I was building the site, I also shipped a product.

It’s called Dartform.

Dartform is a dart backend tooling I built for Flutter + Serverpod developers. It takes your entire backend (all those generated models, relations, and endpoints) and puts them on a visual canvas so you can actually see what you’ve built.

I made it because I kept getting lost in my own projects. Opening a Serverpod codebase and spending ten minutes just remembering what connects to what. There was no map. So I built one.

It launched quietly. People are using it. And this month, I want to share something special with the people who’ve been reading my work here.

A small thank-you. Fifty spots. One discount.

To celebrate the move to Mobterest Studio, I’m opening 50 founding member spots.

Each one comes with a 30% discount on your first month of Dartform, delivered straight to your inbox the moment you sign up. Just your code, ready to go.

It’s April only. The spots are limited. And when they’re gone, that’s that.

If Dartform sounds like something your Serverpod workflow has been missing or you’re curious of what Dartform is, this is a lovely moment to try it.

→ Grab your founding member spot here: mobterest.studio/join

What about this Medium page?

Still here. Not going anywhere.

But the full articles now live on mobterest.studio. When something new goes up, I may post a teaser here so you know about it.

Think of it as a friendly nudge from an old neighbourhood, pointing you somewhere warmer.

Thank you for reading. Thank you for following along through all the mobile engineering rabbit holes and Flutter architecture tangents.

The best is genuinely still ahead.

Can’t wait to see you in the next article! 👋

But when I started reading the code, I noticed something alarming.

The OpenAI client had been instantiated twenty-three times across the project.

Twenty-three.

• Different widgets were making raw HTTP calls directly inside their logic.
• Some calls were inside build() methods.
• API keys were passed around as strings.
• There was no retry logic.
• No error handling beyond a catch (e).
• And absolutely no abstraction layer between the app and the AI provider.

Technically, the feature worked.

Architecturally, it was a time bomb.

The reality is simple.

• AI providers change.
• APIs evolve.
• Rate limits happen.
• Networks fail.

And if your application talks directly to an external AI service without any protective layer, every single one of those changes becomes a breaking change in your app.

That realization pushed me to rethink how AI integrations should be built in mobile applications. Instead of treating AI like a simple HTTP request, I started treating it like infrastructure.

And that changes everything.

The first step was understanding what an AI integration layer actually needs to do.

Most developers think of it as a thin wrapper around an API. But in practice, a reliable AI layer carries several responsibilities.

Your features should not know which AI provider they are talking to.

• Maybe today you use OpenAI.
• Tomorrow it might be Anthropic, Gemini, or even your own hosted model.

If your UI depends directly on a specific provider’s API format, switching becomes a nightmare.

Your AI layer should also handle the reality of unreliable networks.

• APIs return errors.
• Requests time out.
• Rate limits appear when traffic spikes.

A production application needs retry logic, graceful error handling, and predictable failure behavior.

Then there is observability. Every AI request has a cost, both in latency and tokens. If you do not track these metrics, you are flying blind.

Logging token usage and response times is not a luxury. It is operational visibility.

Testability matters too. When your app’s logic depends on an external model, you need the ability to simulate responses without hitting a real API.

That means mocking the AI provider entirely and running tests without network calls or API keys.

Finally, configuration should never be hardcoded.

API keys, models, token limits, and temperature settings should be injected into your system. They should not live inside widgets or random service files.

Once I started thinking about AI integrations through this lens, the architecture became clearer.

Instead of features talking directly to an AI provider, they talk to a service layer. That service depends on a provider interface, which can be implemented by different providers such as OpenAI or Anthropic. Around that provider sits middleware that handles retries, timeouts, and error normalization. Observers collect metrics and logs. The application itself only interacts with the top-level service.

Each layer has one job.

And none of them know more than they need to.

The result is something surprisingly powerful: provider independence.

If your application needs to switch from OpenAI to another provider, you do not rewrite features. You swap the provider implementation and everything above it continues to work.

The real payoff shows up when you start writing tests.

In the old setup, testing meant calling the real API or writing fragile mocks around HTTP responses. Both approaches create unreliable tests.

But with a provider interface in place, you can build a mock AI provider that returns predictable responses instantly. Your application logic runs exactly the same way it would in production, but without touching the network.

Tests become faster, cheaper, and far more reliable.

If you want to see how this architecture actually comes together in a real dart project, including the provider contracts, retry logic, streaming responses, and testing strategy, I walk through the full implementation in this video.

In the tutorial, I showcase the entire layer step by step using Dart, dio, freezed, and dependency injection get_it so you can see exactly how the pieces fit together.

While you’re there, if you can do me a favour, hit the subscribe button. It means alot to me and the mobterest studio team. Thank you.

The meeting started like most product planning sessions. The PM pulled up a slide deck titled “AI-Powered Features Roadmap” and walked through three ambitious features:

• real-time translation during video calls,
• intelligent photo search, and
• a conversational assistant for app navigation.

The design mocks looked polished. The user research validated the need. Everything seemed straightforward until someone asked the question that changed the entire conversation:

“Where does the AI actually run?”

The room went quiet.

• The designers hadn’t considered it.
• The PM assumed “the cloud, obviously.”

And I sat there knowing that this single architectural decision would determine whether these features shipped on time, stayed within budget, or even worked reliably in the real world.

This is the conversation happening in mobile teams everywhere right now. AI isn’t a nice-to-have anymore; it’s becoming table stakes.

But unlike adding a new API endpoint or integrating a third-party SDK, choosing between on-device and cloud AI isn’t just a technical decision.

It’s a product decision, a cost decision, and increasingly, a trust decision.

The “right” answer is almost never obvious upfront. So let me walk you through how I actually think about this problem when it lands on my desk.

The Question Nobody Asks First

Before we dive into latency numbers or model sizes, there’s a more fundamental question that most teams skip:

What happens when the AI fails?

Not “if” but when.

Because AI features fail differently than traditional features. A button either works or it doesn’t.

• An AI model might work perfectly 95% of the time and catastrophically fail the other 5%.
• It might hallucinate.
• It might be confidently wrong.
• It might work great in testing and poorly in production with real user data.

Understanding your failure tolerance shapes everything else.

• If you’re building a photo editor where the AI suggests filters, failure is annoying but recoverable; users just pick manually.
• If you’re building a medical app where AI flags potential health concerns, failure could be dangerous, and you need different guardrails entirely.

This failure analysis should happen before you write a single line of code, because it fundamentally influences whether on-device or cloud AI even makes sense for your use case.

The Real Tradeoffs

Every vendor pitches their approach as superior.

Cloud AI providers talk about unlimited model complexity and continuous improvements.

On-device AI frameworks emphasize privacy and zero latency.

Both are selectively highlighting strengths while glossing over real limitations.

Here’s what actually matters in production:

Latency and User Experience

Cloud AI means network round-trips. Even with a fast connection, you’re looking at 200–500ms minimum for a typical inference request; more if you’re doing something complex like image generation or multi-turn conversation. That’s noticeable. Users feel it.

On-device AI runs in milliseconds once the model loads. But “once the model loads” is doing a lot of work in that sentence. Cold starts can take seconds if you’re loading a large model into memory. The first inference after app launch might be slower than cloud, even though subsequent ones are instant.

The experience difference shows up in different ways:

• Cloud: Consistent latency, but always present. Every request feels the same, which can be good or bad depending on what you’re building.
• On-device: Variable latency. First use is slow, then it’s blazing fast. This works great for features users interact with repeatedly in a session, but poorly for one-off actions.

Privacy and Data Control

This is where the conversation gets interesting, because privacy isn’t binary. It exists on a spectrum, and your users care about different points on that spectrum depending on the feature.

On-device AI means data never leaves the phone. For sensitive features (health tracking, financial analysis, personal journaling), this is compelling.

You’re not just protecting user privacy; you’re removing entire classes of security concerns.

• No server to breach.
• No logs to leak.
• No compliance headaches around data retention.

But here’s the nuance: on-device doesn’t automatically mean more private if you’re still sending telemetry, crash reports, or analytics that contain the outputs of your AI models. And cloud doesn’t automatically mean less private if you’re using edge computing, encrypting requests end-to-end, and never persisting user data.

The real question is: Do users understand and trust how you’re handling their data? That’s a product and communication challenge as much as a technical one.

Cost Structure

Cloud AI has a predictable cost model that scales with usage.

Every API call costs money.

Do the math: if you’re making 10 million inferences per month at $0.001 per inference, that’s $10,000 monthly. Scale to 100 million users, and you’re looking at serious infrastructure spend.

On-device AI flips the cost model.

Your upfront costs are higher (model development, optimization, testing across device types) but marginal costs are nearly zero. Once the model ships in your app, it runs on user devices for free (from your perspective).

The crossover point depends entirely on your scale.

For a new app with 10,000 users, cloud is probably cheaper.

For an established app with millions of active users, on-device might save hundreds of thousands annually.

But you need to factor in the engineering investment to actually ship on-device models reliably.

Model Capability and Flexibility

Cloud models can be enormous. GPT-4, Claude, Gemini; these are multi-billion parameter models running on server farms. You get state-of-the-art performance, and when the provider ships an update, you get improvements automatically.

On-device models are constrained by phone hardware. You’re typically working with models in the tens to hundreds of millions of parameters, not billions. They’re optimized, quantized, and pruned to fit in limited memory and run on mobile GPUs or NPUs. Performance is good for focused tasks, but you’re not getting GPT-4 quality on a phone.

There’s also a flexibility gap.

With cloud, you can A/B test new models, roll back bad deployments, and iterate rapidly. With on-device, you’re locked to the model you shipped until the next app update. If you discover a quality issue, you can’t hot-fix it; you’re waiting on app store review cycles.

Device Fragmentation

This is the part that doesn’t show up in vendor demos but absolutely matters in production.

On-device AI performance varies wildly across device types. An iPhone 15 Pro with an A17 chip runs models beautifully. A three-year-old Android phone with a mid-range processor might struggle or not support the model at all. You end up maintaining fallback paths, degraded experiences, or just excluding huge portions of your user base.

Cloud AI is democratizing in this sense; any device with a network connection gets the same model quality. Your 2020 Android phone gets the same AI experience as the latest iPhone, because the heavy lifting happens server-side.

But that democratization comes with its own equity issues. Users on slow or metered connections in developing markets get hammered with latency and data costs. On-device models actually work better for them, if their hardware supports it.

My Decision Framework in Practice

When I’m evaluating on-device vs cloud for a specific feature, I walk through this framework. It’s a structured way to think through the tradeoffs systematically.

Step 1: Define the Feature’s Core Constraints

Start by answering these questions honestly:

What’s the latency requirement?

• Real-time (< 100ms): Probably on-device
• Interactive (< 1s): Could go either way
• Background/async (> 1s): Cloud is fine

What’s the privacy sensitivity?

• High (health, finance, personal): Strongly consider on-device
• Medium (preferences, habits): Depends on user expectations
• Low (public data, non-personal): Cloud is often simpler

What’s the expected usage pattern?

• High frequency, same session: On-device wins
• Sporadic, one-off: Cloud is fine
• Varies by user: Hybrid approach

What’s your scale?

• < 100k users: Cloud is likely cheaper
• 100k — 1M users: Do the math
• 1M users: On-device probably pays off

Step 2: Evaluate Your Technical Capabilities

On-device AI isn’t just “download a model and run it.” It requires:

• Model optimization expertise: Can your team quantize, prune, and optimize models for mobile?
• Platform-specific knowledge: Do you understand Core ML, TensorFlow Lite, NNAPI quirks?
• Testing infrastructure: Can you validate model performance across dozens of device types?
• Update mechanisms: Do you have a way to ship model updates outside of app releases?

If the answer to most of these is “no” or “we’d need to learn,” cloud AI significantly reduces your technical risk. You’re delegating the hard parts to a vendor who’s already solved them.

Step 3: Consider the Hybrid Approach

Start with cloud, migrate to on-device strategically.

Ship your AI feature on cloud infrastructure first. This lets you:

• Validate product-market fit without huge upfront investment
• Iterate rapidly on model quality and feature UX
• Gather real usage data to inform on-device optimization
• Build confidence in the feature before committing to on-device complexity

Then, once the feature proves valuable and you understand usage patterns, invest in on-device models for:

• High-frequency interactions where latency matters
• Privacy-sensitive use cases where users explicitly care
• Cost reduction if cloud inference bills are becoming significant

You can even run hybrid architectures where simple inferences happen on-device and complex ones fall back to cloud.

- Photo search might do initial filtering on-device, then use cloud for complex semantic queries.

- Translation might handle common phrases on-device and use cloud for rare languages or technical terminology.

Step 4: Plan for Model Governance

AI models need ongoing governance, regardless of where they run.

For cloud AI:

• How do you monitor inference quality over time?
• What’s your rollback plan if a new model version performs poorly?
• How do you handle cost spikes if usage exceeds projections?
• What happens when your AI provider has an outage?

For on-device AI:

• How do you ship model updates between app releases?
• What’s your testing matrix across device types and OS versions?
• How do you handle devices that can’t run your model?
• What’s your deprecation strategy for old models?

These aren’t one-time decisions. They’re ongoing operational concerns that need process, tooling, and someone’s ownership.

Real Examples from Production

Let me ground this in actual features I’ve worked on or closely studied:

Photo Search in Apple Photos (On-Device)

Apple’s Photos app does facial recognition, object detection, and scene classification entirely on-device. The models run during phone charging overnight, building a searchable index without ever sending photos to Apple’s servers.

Why on-device worked:

• Privacy is core to Apple’s brand positioning
• Processing can happen asynchronously in the background
• Models only need to run periodically, not real-time
• Users query their photos frequently once indexed (amortizes the indexing cost)

The tradeoff:

• Initial indexing takes hours
• Search quality is good but not as sophisticated as Google Photos’ cloud approach
• Older devices with less powerful chips get degraded performance

Google Translate Real-Time Translation (Hybrid)

Google Translate’s conversation mode and camera translation use on-device models for speed, but fall back to cloud for accuracy and unsupported languages.

Why hybrid worked:

• Common language pairs (English-Spanish) can run on-device for instant results
• Rare languages or complex sentences gracefully degrade to cloud
• Users are happy with fast “good enough” translations most of the time
• When users explicitly need higher quality, they can wait for cloud

The tradeoff:

• More complex architecture to maintain
• Edge cases where on-device fails but cloud would succeed
• Users don’t always understand why some translations are instant and others aren’t

Grammarly’s Writing Suggestions (Cloud)

Grammarly runs almost entirely in the cloud, even though this means every keystroke potentially triggers a network request.

Why cloud worked:

• Writing is inherently high-latency tolerant (users pause to think)
• Model complexity required for good suggestions exceeds mobile capabilities
• Continuous model updates improve quality without app releases
• Cross-platform consistency (web, mobile, desktop) all use the same models

The tradeoff:

• Requires network connectivity to function
• Privacy concerns led them to add explicit opt-out for sensitive documents
• Subscription model helps offset cloud infrastructure costs

The Uncomfortable Truth About AI Architecture

Your architecture choice will probably be wrong initially, and that’s okay.

• You’ll choose on-device, then realize the model quality isn’t good enough and switch to cloud.
• Or you’ll choose cloud, then get a surprise bill for $50,000 in inference costs and scramble to move workloads on-device.
• Or you’ll ship a hybrid approach that’s so complex nobody can debug it when things break.

This isn’t a failure of planning. It’s the nature of working with AI in production. Usage patterns surprise you. Model performance in the wild differs from testing. User expectations shift. The technology itself evolves rapidly.

The teams that succeed aren’t the ones who make perfect decisions upfront. They’re the ones who:

• Build with flexibility; architecture that can shift between on-device and cloud without rewriting everything
• Measure relentlessly; instrumentation that shows actual latency, costs, quality metrics in production
• Communicate honestly; setting realistic expectations with stakeholders about uncertainty and iteration
• Stay technical; decision-makers who understand enough about the technology to ask good questions

What I’d Do If I Were Starting Today

If you’re reading this because you’re facing this decision right now, here’s my practical advice:

For your first AI feature: Start with cloud unless you have strong privacy requirements that make it impossible. You’ll ship faster, iterate more easily, and learn what actually matters to users before committing to on-device complexity.

For privacy-sensitive features: Go on-device if you can, but be realistic about the engineering investment. If your team doesn’t have mobile ML experience, factor in months of learning and experimentation. Cloud with strong encryption and data guarantees might be the pragmatic choice.

For high-scale, established apps: Run the cost analysis seriously. At millions of users, on-device AI can save enough money to fund entire engineering teams. But build incrementally; start with one feature, prove the pipeline works, then expand.

For real-time, interactive features: On-device is almost always better if you can make the model work. The latency difference is user-perceptible and compounds over repeated interactions.

And regardless of what you choose: plan for change. Don’t architect yourself into a corner where switching approaches requires rewriting your entire app. The AI landscape is moving too fast for that kind of rigidity.

The Bigger Picture

Five years from now, I suspect this on-device vs cloud question will feel quaint. We’re already seeing edge computing blur the lines; models running on CDN nodes geographically close to users, giving cloud-like flexibility with near-device latency.

We’re seeing federated learning where on-device models improve from collective usage without centralizing data.

We’re seeing hybrid architectures that dynamically route inference based on network conditions, device capabilities, and feature requirements.

But right now, in 2026, we’re still figuring this out. And that’s okay. You don’t need to have all the answers. You need to understand the tradeoffs, make informed decisions with the information you have, and build systems that can evolve as you learn more.

At the end of the day, users don’t care whether your AI runs on their device or in the cloud. They care whether it works, whether it’s fast, whether they trust it, and whether it actually makes their lives better.

Everything else is just implementation details.

👏🏽 If you enjoyed this story, give it some CLAPS!

Stay in the loop for more insights on mobile development:
💡 Subscribe for upcoming articles
📚 Access free tutorials
🔔 Follow for updates

Support what we’re building at Mobterest Studio:
🤝 Join our community or contribute here
✉️ Subscribe to our newsletter for exclusive content

Can’t wait to see you in the next article! 👋

With traditional Firestore, you’d hit a wall pretty quickly. You’d end up maintaining extra collections just to track aggregated data, or worse, downloading thousands of documents to your app and doing the calculations there. It worked, but it felt like using a hammer when you really needed a power drill.

That just changed 👇🏽

What Firebase Just Announced

Firebase and Google Cloud just unveiled Firestore Pipeline Operations: a completely reimagined query engine that gives you over a hundred new ways to ask questions of your data. This isn’t a minor update.

This is Firestore growing up from “really good for simple queries” to “can handle complex data operations that used to require a separate analytics database.”

The key phrase to understand is “pipeline operations.” Think of it like an assembly line for your data. You start with your documents, then pass them through different stages; filtering, transforming, aggregating, until you get exactly what you need. Each stage does one thing, and you chain them together to build powerful queries.

A Real Example That Makes It Click

Let’s say you’re building a recipe app. Users can tag recipes with things like “easy,” “high protein,” “low carb.” Each recipe document has an array of these tags:

{
  title: "Grilled Chicken Salad",
  instructions: "Grill the chicken, toss the salad...",
  tags: ["easy", "high protein", "low carb"]
}

Now you want to show users a “trending tags” feature (the top 10 most popular tags across all recipes). With old Firestore, you couldn’t do this directly. You’d need to maintain a separate “tags” collection and update counts manually every time someone added or removed a tag from a recipe. It was maintenance overhead that felt unnecessary.

With Pipeline Operations, you can just ask for it:

const snapshot = await db.pipeline()
  .collection("recipes")
  .unnest(field("tags").as("tagName"))
  .aggregate({
    accumulators: [countAll().as("tagCount")],
    groups: ["tagName"]
  })
  .sort(field("tagCount").descending())
  .limit(10)
  .execute()

Let me walk you through what’s happening here, step by step:

1. Start with the recipes collection. You’re looking at all your recipe documents
2. Unnest the tags. This “explodes” each recipe into separate rows for each tag. If a recipe has 3 tags, it becomes 3 rows
3. Aggregate and count. Group all those rows by tag name and count how many times each tag appears
4. Sort by popularity. Put the most common tags first
5. Limit to top 10. Only return the ten most popular

That’s it.

• No extra collections to maintain.
• No client-side processing.
• No batch jobs running in the background to keep counts updated.

You just ask the question, and Firestore answers it.

Why This Matters for Mobile Developers

As a mobile developer, you’ve probably felt the tension between what your database can do and what your app needs to show users. You design a beautiful UI, but then realize the backend query to power it requires downloading way more data than necessary, or running calculations on the client that should really happen on the server.

Pipeline Operations shifts that balance. Now you can:

• Aggregate data without maintaining separate collections. Count things, sum values, find averages, all within a query.
• Transform data before it reaches your app. Reshape documents, extract nested fields, convert data types.
• Use regular expressions in queries. Search text fields with pattern matching instead of exact matches.
• Chain operations together . Combine filtering, sorting, grouping, and transforming in a single query.

The practical impact? Your apps can do more sophisticated data operations without bloating client-side code or over-fetching data.

You’re querying smarter, not harder.

The Two Flavors: Standard vs. Enterprise Edition

Here’s where it gets a bit nuanced. Firestore now exists in two editions.

Standard Edition is what you already know. It automatically creates indexes for you, makes queries fast by requiring those indexes, and has the simple query API you’re familiar with. It’s not going away. If your app works fine today, you can keep using it forever.

Enterprise Edition is the new hotness with Pipeline Operations. But it works differently:

• No automatic indexes. You decide what to index based on your actual query patterns
• Queries work without indexes. They’ll just be slow on large collections until you add indexes
• Different pricing model. Writes and deletes are both just “write operations” and you get a generous free tier.
• Over 100 new query capabilities. All the Pipeline Operations goodness

Despite the name “Enterprise,” it’s not just for big companies. Firebase gives you a free tier for Enterprise edition just like Standard. The name is more about capability than audience.

Should You Switch Right Now?

Probably not immediately. Here’s my honest take.

If you’re starting a brand new project, Enterprise Edition is worth considering from day one. You get more flexible querying, often better free tier coverage (especially if you do a lot of writes), and you won’t have to migrate later if you need Pipeline Operations.

If you have an existing app on Standard Edition, switching requires actual work. You need to:

• Export your data and import it into a new Enterprise database
• Recreate your indexes manually
• Set up security rules again
• Update your SDK initialization code
• Test everything thoroughly

That’s not trivial. So unless you’re hitting real limitations with Standard Edition queries, there’s no rush. Standard Edition isn’t deprecated. Your existing queries will keep working exactly as they do today.

The sweet spot for migration is when you’re planning a major feature that would benefit from complex querying, or when you’re already doing a database architecture overhaul. Otherwise, bookmark this for later.

The Practical Stuff: How to Actually Use It

If you decide to try Enterprise Edition, the process is straightforward:

1. Create a new Enterprise database in your Firebase console (you can have multiple databases in one project)
2. Update your Firestore SDK to the latest version
3. Point your app to the new database by specifying its name when you initialize:

const db = new Firestore({
  projectId: "your-project-id",
  databaseId: "your-enterprise-database"
});

4. Convert existing queries to pipelines if you want, or just write new pipeline-based queries:

// Old way
const query = db.collection("recipes").where("authorId", "==", user.id);
// Convert to pipeline
const pipeline = db.pipeline().createFrom(query);
// Now extend it with new capabilities
const results = await pipeline
  .where(field("rating").greaterThan(4))
  .execute();

The SDKs support Android, iOS, Web, and the Admin SDK right now. Flutter, Unity, and C++ support is coming soon.

What This Really Means Long-Term

For years, one of Firestore’s biggest criticisms was that it couldn’t handle complex queries. Developers would choose PostgreSQL or MongoDB specifically because they needed aggregations, complex joins, or flexible querying that Firestore simply couldn’t do.

Pipeline Operations closes that gap. Firestore now competes feature-wise with major NoSQL databases while keeping the things that made it special: real-time sync, offline caching, tight Firebase integration, and a developer experience that doesn’t require becoming a database expert.

This update isn’t just about adding features. It’s about Firestore growing into the kind of database you can build an entire production app on without constantly working around its limitations.

Where to Go From Here

For now, just know this: Firestore got a lot more powerful. And whether you switch today or bookmark it for later, Pipeline Operations are worth understanding because they fundamentally change what’s possible in your mobile apps.

Follow along on Mobterest Studio to learn more about Firebase, mobile architecture, and making better technical decisions in your apps.

I ran a poll asking:

“Do you check the pub.dev score before adding a package?”

The results told a story.

So let me break down:

• what the pub.dev score actually means,
• why it exists, and
• most importantly, why skipping it is one of the quietest ways to introduce a security risk into your Flutter app.

The pub.dev score has 3 dimensions.

Pub Points (out of 130)

This is the quality score. It’s calculated automatically by a tool called pana every time a package is published. It checks things like:

• does it follow code conventions,
• is it documented,
• does it have a valid license,
• are its URLs secure (https),
• does it support current Dart and Flutter SDKs, and
• are its dependencies up to date?

A package near 130/130 is well-maintained and structured.

A package at 40/130 is telling you something.

Likes

These are raw community sentiment of how many developers liked it. It’s a peer signal, not a quality guarantee; but combined with the other metrics, it’s useful context.

Downloads

It refers to how often the package is downloaded.

High downloads mean wide adoption.

But this number can be inflated by CI/CD systems running repeated builds so don’t treat it as a standalone trust signal.

Here’s what most devs don’t consider.

A package can have thousands of downloads and still be dangerous. Download count doesn’t tell you:

• When the package was last maintained
• Whether known vulnerabilities have been reported
• Whether the encryption or network handling methods it uses are still current
• Whether its own dependencies are outdated

In The Secure Flutter Handbook (Chapter 7, p.68), I cover this directly. Using a deprecated or unmaintained package means you might be inheriting:

• weak encryption methods,
• insecure network handling,
• and unsafe defaults that newer APIs have already fixed.

And the worst part is that your app won’t crash. It won’t throw an error. It will just work. Silently shipping risk.

What to actually check before adding a Flutter package

→ Pub Points: aim for 100+ out of 130

→ Last published date: within the last 6 months is a healthy signal

→ GitHub issues: search for “security” and read what comes up

→ Dart/Flutter SDK compatibility: confirm it supports your current version → Flutter Favourites badge: packages reviewed and endorsed by the Flutter team

Staying updated isn’t just about getting new features. It’s about not inheriting yesterday’s vulnerabilities.

This is one of the five checks I cover in Chapter 7 of The Secure Flutter Handbook. You can access the full picture (12 chapters on real Flutter security vulnerabilities and how to fix them).

What does your package vetting process look like? I’m curious how teams handle this. Drop it in the comments 👇

Follow Mobterest Studio. for hands-on mobile engineering tutorials from a senior architect’s perspective. We go beyond code to explore the systems, processes, and mindsets that make mobile architects successful.

👏🏽 If you enjoyed this story, give it some CLAPS!

Stay in the loop for more insights on mobile architecture:
💡 Subscribe for upcoming articles
📚 Access free tutorials
🔔 Follow for updates

Support what we’re building at Mobterest Studio:
🤝 Join our community or contribute here
✉️ Subscribe to our newsletter for exclusive content

Can’t wait to see you in the next article! 👋

I still remember the first time a production build failed at 4 PM on a Friday. The QA team had approved everything. The product manager was ready to announce the release. And there I was, frantically trying to figure out why the exact same code that worked on my machine refused to build on our CI server.

The worst part is that it wasn’t even a code problem. It was a mismatched Xcode version, a cached dependency from two sprints ago, and a signing certificate that had quietly expired the night before. By the time I’d tracked down all three issues, it was 9 PM, and I’d missed my son’s bedtime routine.

That painful evening taught me something crucial: deployment problems aren’t really about code. They’re about consistency, automation, and trust in your process. And for mobile teams especially, where we’re juggling multiple platforms, device configurations, and app store requirements, having a reliable CI/CD pipeline isn’t a luxury; it’s survival.

The Mobile Deployment Trap

Mobile development has a unique flavor of chaos when it comes to deployments. Unlike web applications where you can push fixes instantly, we’re working within the constraints of app store review cycles, device fragmentation, and user update patterns. A broken build doesn’t just delay your sprint, it can cascade into missed marketing windows, stale beta feedback, and a team that’s too afraid to merge anything on Thursdays.

Most mobile teams I’ve worked with start the same way: manually building releases, passing APKs and IPAs through email or Slack, hoping nobody forgets to increment the build number. It feels manageable when you’re three developers working on an MVP. But the moment you hit product-market fit and scale to multiple feature teams, that manual process becomes a bottleneck that drains velocity and morale.

CI/CD solves this by turning deployment into a predictable, repeatable, and most importantly boring process. When your pipeline works correctly, nobody thinks about it. And that’s exactly the point.

Why GitHub Actions Makes Sense for Mobile Teams

I’ve used Bitrise, and Codemagic across different projects. Each has strengths. But if you’re already on GitHub and you’re building a new mobile CI/CD pipeline from scratch, GitHub Actions deserves serious consideration. Here’s why.

It’s already where your code lives. There’s no context-switching between your repository and some external CI dashboard. Pull requests show workflow status inline. Code reviewers can see exactly which checks passed or failed without leaving GitHub. It sounds small, but this integration removes friction in ways you don’t appreciate until you’ve worked without it.

The pricing model is developer-friendly. Public repositories get unlimited Actions minutes. For private repos, even the free tier gives you 2,000 minutes per month, which is surprisingly generous for small-to-medium mobile teams. Compare that to specialty mobile CI services charging hundreds per month, and you start to see the appeal especially for side projects, open-source libraries, or early-stage startups watching their burn rate.

Workflows are version-controlled YAML files. This might seem like a technical detail, but it’s transformative. Your CI configuration sits right alongside your code in .github/workflows/. When you branch off to build a new feature, you can modify the pipeline to test that feature without affecting the main branch. When something breaks, you can trace exactly when and why the pipeline changed. No more "it worked yesterday" mysteries because someone tweaked a setting in a web UI.

The Actions Marketplace is a force multiplier. Instead of writing bash scripts to set up Xcode, manage Android SDK versions, or cache Flutter dependencies, you can pull pre-built actions that hundreds of developers have already tested and refined. Need to upload your APK to Firebase App Distribution? There’s an action for that. Want to post build results to Slack? Someone built it. This ecosystem effect means you’re solving novel problems, not reinventing wheels.

Understanding the Building Blocks

Before we dive into mobile-specific implementations, let’s clarify the core concepts. GitHub Actions can feel overwhelming at first because you’re learning both a new syntax and new mental models simultaneously. But once you grasp these fundamentals, everything else clicks into place.

Workflows are the top-level automation scripts. Each workflow is a YAML file in your .github/workflows/ directory. You might have one workflow for running tests on every pull request, another for building release candidates when you tag a version, and a third for nightly builds that run against the latest dependencies. Workflows are independent and can run in parallel or sequence based on your triggers.

Jobs are the major steps within a workflow. Think of them as logical groupings of work. In a mobile context, you might have a “Build” job that compiles your app, a “Test” job that runs your unit and integration tests, and a “Deploy” job that uploads artifacts to TestFlight or Play Console. By default, jobs run in parallel to save time, but you can specify dependencies when one job needs to complete before another starts.

Steps are the individual commands within a job. This is where the actual work happens: checking out your code, installing dependencies, running build commands, uploading artifacts. Each step is either a shell command (like flutter build apk --release) or a reference to an action from the Marketplace (like actions/setup-java@v3).

Runners are the machines that execute your workflows. GitHub provides hosted runners with Ubuntu, Windows, and macOS environments. For mobile development, macOS runners are essential for iOS builds since Xcode only runs on macOS. GitHub’s macOS runners come pre-installed with multiple Xcode versions, saving you from painful setup scripts.

Triggers define when workflows run. The most common trigger is on: push, which runs your workflow every time someone pushes code. But you can also trigger on pull requests, on schedule (using cron syntax for nightly builds), manually via workflow_dispatch, or even in response to external webhooks. Getting your triggers right is crucial; you don't want to burn through runner minutes building every experimental branch, but you also need confidence that main branch deployments are always tested.

Secrets let you store sensitive data like API keys, signing certificates, and keystore passwords. These are encrypted and only exposed to your workflow at runtime. Never hardcode credentials in your YAML files or commit them to your repository. GitHub’s secrets management integrates with your workflow seamlessly, letting you reference values as ${{ secrets.ANDROID_KEYSTORE_PASSWORD }} without exposing the actual content.

Artifacts and caching are performance optimizations. Artifacts let you persist build outputs (like APKs or IPAs) between jobs or after a workflow completes. Caching saves dependencies or build intermediates so subsequent runs don’t have to re-download or recompile from scratch. A well-configured cache can cut your mobile build times from 15 minutes to 5 minutes, which compounds dramatically over hundreds of builds per month.

Mobile-Specific Challenges and Solutions

Here’s where mobile development diverges from typical web CI/CD patterns. You’re not just compiling code, you’re managing platform-specific toolchains, signing configurations, and binary artifacts that need to end up in tightly controlled app stores.

iOS: The Certificate Dance

iOS builds are notoriously finicky. You need the right Xcode version, the correct provisioning profile, and signing certificates that match your Apple Developer account. Get any of these wrong, and your build fails with cryptic errors about entitlements or code signing identities.

GitHub Actions helps by providing macOS runners with multiple Xcode versions pre-installed. You can specify which version to use with a simple step:

yaml

- name: Select Xcode version
  run: sudo xcode-select -s /Applications/Xcode_15.0.app

For certificates and provisioning profiles, the secure approach is to store them as base64-encoded secrets, then decode them at runtime into your build environment. It’s not elegant, but it keeps sensitive files out of your repository while still automating the process. Community actions like apple-actions/import-codesign-certs handle much of this ceremony for you.

The painful reality is that iOS CI requires more upfront setup than Android. But once configured, it’s remarkably stable. Apple’s tooling changes slowly enough that a well-written workflow can run for months without modification.

Android: Keystore Management

Android signing is comparatively straightforward, but keystore files and passwords still need careful handling. The pattern I’ve seen work reliably is storing your keystore as a base64-encoded secret, decoding it to a file during the workflow run, and passing keystore properties through environment variables.

Your build.gradle needs to read these properties at build time rather than hardcoding paths or passwords. This separation means the same configuration works locally (reading from local.properties), in CI (reading from environment variables), and in any developer's machine without sharing sensitive credentials through Slack or email.

Android also benefits enormously from dependency caching. Gradle’s build cache and downloaded libraries can be cached between runs using actions/cache, dramatically speeding up builds. A Flutter Android build that takes 12 minutes cold can drop to 3-4 minutes when cache hits are consistent.

Flutter: Platform-Specific Builds in One Workflow

Flutter introduces an interesting challenge: you’re often building for both iOS and Android from the same codebase. This means your workflow needs to handle platform-specific steps conditionally while sharing common setup like Flutter SDK installation.

The subosito/flutter-action handles SDK installation and caching elegantly. Once that’s in place, you can split into parallel jobs for iOS and Android builds, or sequence them if you’re concerned about runner concurrency limits. The key insight is that Flutter’s platform channels and native dependencies mean you’re really running two separate builds that happen to share Dart code. Your CI pipeline should reflect that reality.

When GitHub Actions Might Not Be the Answer

I’ve spent most of this article advocating for GitHub Actions, but let’s be clear-eyed about its limitations. No tool is perfect for every context, and mobile CI/CD is complex enough that your team’s specific constraints matter.

Enterprise security and compliance requirements sometimes demand self-hosted infrastructure with strict network isolation, audit logging, and air-gapped environments. GitHub’s hosted runners send build logs and artifacts through GitHub’s infrastructure. If your organization has regulatory requirements that prohibit this, you’ll need self-hosted runners or an on-premise CI solution, which removes much of GitHub Actions’ convenience advantage.

Extremely complex build matrices. Think dozens of combinations of OS versions, device types, and feature flags that need exhaustive testing! They can become expensive and slow on GitHub Actions. Specialty mobile CI platforms like Bitrise or AWS Device Farm are optimized for this kind of massive parallelization with real device testing. If you’re running UI tests across 50 device configurations, GitHub Actions’ macOS runner costs can balloon quickly.

Teams deeply invested in existing CI tooling should think carefully before migrating. If you’ve got hundreds of Jenkins pipelines, custom plugins, and institutional knowledge built over years, switching to GitHub Actions isn’t free. The migration itself is work, and there’s a learning curve that temporarily slows your team down. Sometimes the right answer is to incrementally improve what you have rather than chase a newer solution.

That said, for most mobile teams, especially those starting fresh or frustrated with their current setup , GitHub Actions hits a sweet spot of power, cost, and integration that’s hard to beat.

What Comes Next

Understanding GitHub Actions conceptually is the first step. But mobile CI/CD isn’t something you learn by reading, you learn by breaking things, fixing them, and gradually building confidence in your automation.

In the coming weeks on the Mobterest Studio YouTube channel, I’m walking through Flutter CI/CD workflows. The goal isn’t just to copy-paste a working example (though you’re welcome to). It’s to understand the patterns well enough that you can adapt them to your team’s specific needs. Whether you’re building a side project, scaling a startup, or modernizing a legacy mobile app, having reliable deployment automation changes how you work.

At the end of the day, the goal isn’t perfect CI/CD. The goal is shipping value to users without the constant anxiety that your build might fail at 4 PM on a Friday.

Follow Mobterest Studio on YouTube. for hands-on mobile engineering tutorials from a senior architect’s perspective. We go beyond code to explore the systems, processes, and mindsets that make mobile teams successful.

I used to think testing was the boring part of mobile development. Not because it was unimportant, but because it felt disconnected from reality. I would run my app on my phone, maybe try a simulator, tap around a bit, and if nothing crashed, I convinced myself it was “good enough.” At the time, that felt like progress. In hindsight, it was optimism disguised as confidence.

The wake-up call usually came after release. A user would report a bug I could not reproduce. Another would complain that the app froze on a device I did not own. Sometimes everything worked perfectly for me but failed under slow networks, older phones, or low battery conditions. Each time, I found myself thinking, “How did this slip through?” The uncomfortable answer was always the same: I never really tested the app in the world it was going to live in.

That was my first real lesson about automated mobile testing.

It is not about replacing developers with robots or writing endless test scripts.

It is about acknowledging a simple truth: as a mobile architec, I am too close to my own app. I know where everything is. I know the happy paths. Real users do not behave like that. They tap quickly, lose connection, rotate screens at the worst possible time, and use devices I have never even held.

I remember a conversation with another developer who said something that stuck with me. He told me that manual testing is like proofreading your own writing. You can do it, but you will always miss something because your brain fills in the gaps.

Automated testing, especially on real devices, is like handing your work to someone who has never seen it before and asking them to try to break it. That framing completely changed how I thought about testing.

When I started using automated testing, the biggest shift was psychological. I stopped relying on my memory and attention span. Instead of thinking, “Did I remember to test login on slow internet?” I could say, “This test runs every time, under these conditions, whether I remember or not.” That consistency alone removed a lot of anxiety from my release process. It felt like moving from guessing to knowing.

Automated mobile testing, explained simply, is just this:

you write instructions that describe how your app should behave, and you let machines repeat those instructions over and over in environments you cannot realistically recreate by hand. Different devices. Different operating system versions. Different network conditions. The same expectations every time. It is not about testing everything perfectly. It is about reducing the number of surprises that reach your users.

What surprised me most was how human the benefits felt. Fewer late-night hot-fixes. Fewer apologetic replies to app store reviews. Fewer moments of doubt after pressing the release button. Instead of hoping nothing would break, I started trusting the process I had built. That trust did not come from confidence in myself. It came from confidence in the system.

There was also an unexpected side effect. Automated testing forced me to think more clearly about my app’s behavior. When you try to explain to a test what should happen, vague logic stops working. You have to be precise. You have to define what “success” actually means. In a strange way, testing made my app better designed, not just better tested.

Today, I still manually test my apps. I still tap through flows and try to experience them like a user. But I no longer confuse that with real coverage.

Automated testing handles the repetition, the edge cases, and the conditions I cannot predict. Manual testing handles empathy and intuition. Together, they create something that feels much closer to reality.

If I could go back and talk to my earlier self, I would not say, “You need automated testing because it is best practice.” I would say, “You deserve a calmer release day.”

Automated mobile testing is not about being perfect. It is about being prepared. And once you experience that shift, it is very hard to go back.

👏🏽 If you enjoyed this story, give it some CLAPS!

Stay in the loop for more insights on mobile development:
💡 Subscribe for upcoming articles
📚 Access free tutorials
🔔 Follow for updates

Support what we’re building at Mobterest Studio:
🤝 Join our community or contribute here
✉️ Subscribe to our newsletter for exclusive content

Can’t wait to see you in the next article! 👋

If you’ve ever been confused about whether you’re using an emulator or a simulator, or why it even matters, you’re not alone. These terms get thrown around interchangeably in mobile development, but they’re actually quite different. Understanding this distinction will help you make better testing decisions and debug issues more effectively.

The Simple Explanation First

Here’s the quickest way to understand the difference:

Simulator = Pretends to be the device (like an actor playing a role)

Emulator = Actually becomes the device (like a perfect impersonator)

Think of it this way: If you’re learning to drive, a driving simulator (like a video game) simulates the experience, but a real car with dual controls emulates the actual driving environment more faithfully.

The Technical Reality

What is a Simulator?

A simulator mimics the behaviour of a device but runs natively on your computer’s architecture.

Key characteristics:

• Runs the same instruction set as your development machine (typically x86/x64)
• Translates app behaviour to work on your Mac/PC
• Faster performance because there’s no hardware translation
• Less accurate to real device behavior
• iOS Simulator is the classic example

Think of it like this: When you use the iOS Simulator, your Swift/Objective-C code compiles for your Mac’s processor (Intel or Apple Silicon), not for the iPhone’s ARM processor. The simulator creates a window that looks like an iPhone and behaves like iOS, but it’s running on your Mac’s hardware.

What is an Emulator?

An emulator recreates both the software AND hardware of the target device.

Key characteristics:

• Emulates the actual device’s processor architecture (ARM)
• Translates instructions from one architecture to another in real-time
• Slower performance due to hardware emulation overhead
• More accurate representation of real device behaviour
• Android Emulator is the primary example

Think of it like this: The Android Emulator creates a virtual ARM processor on your x86 computer. It has to translate every single ARM instruction to x86 instructions that your computer can understand. This is why it can feel slower, but it’s also why it behaves more like a real device.

Platform Breakdown

iOS: The Simulator Approach

Apple provides the iOS Simulator (not emulator):

Your Mac → iOS Simulator → Your App (compiled for x86/ARM64 Mac)

Why Apple chose simulation:

• Faster development cycle
• Tighter integration with Xcode
• Mac and iOS share similar foundations (both use Darwin kernel)
• Apple Silicon Macs and iOS devices both use ARM, making simulation even more efficient

Important limitation: The iOS Simulator cannot access certain hardware features like:

• Camera (you can select photos, but can’t use live camera)
• Motion sensors (accelerometer, gyroscope)
• True GPS location (you can simulate locations though)
• Cellular network behaviour

Android: The Emulator Approach

Google provides the Android Emulator:

Your Computer → Android Emulator (QEMU-based) → Virtual ARM Device → Your App

Why Google chose emulation:

• Android runs on diverse hardware (ARM, x86, MIPS)
• Need to test on different chipsets and configurations
• More accurate representation of actual device behavior
• Supports hardware acceleration (Intel HAXM, AMD Hypervisor)

Modern improvements:

• x86 Android images available for faster performance
• HAXM (Hardware Accelerated Execution Manager) for Intel CPUs
• Google Play system images for more realistic testing

Real-World Impact: When It Actually Matters

Scenario 1: Performance Testing

❌ Bad approach:

"My animation runs at 60fps in the simulator, so it's good to ship!"

✅ Good approach:

"My animation runs at 60fps in the simulator. Now let me test on a real device
 (or emulator  for Android) to see actual performance."

Why? Simulators run on powerful development machines. Your users’ 3-year-old phones won’t have the same performance.

Scenario 2: Testing Network Conditions

Emulators (Android): Can better simulate poor network conditions, dropped connections, and varying signal strengths because they emulate the actual network stack.

Simulators (iOS): Limited network condition simulation. You can throttle network in Xcode, but it’s less accurate than real device testing.

Scenario 3: Hardware Features

Testing camera integration:

• iOS Simulator: Can select photos, cannot access camera feed
• Android Emulator: Can use your webcam as device camera (limited)
• Real device: Only way to truly test camera features

Testing sensors (accelerometer, gyroscope):

• iOS Simulator: Can simulate some motion through Xcode
• Android Emulator: Can simulate sensor data
• Real device: Only way to test actual sensor behavior accurately

Common Misconceptions Debunked

Myth 1: “Emulators are always slower”

Reality: Modern Android emulators with x86 images and hardware acceleration can be quite fast. The slowness comes from ARM emulation specifically.

Myth 2: “Simulators are not real testing”

Reality: Simulators are excellent for UI testing, logic testing, and rapid iteration. They’re not a replacement for device testing, but they’re valuable tools.

Myth 3: “I only need to test on emulator/simulator”

Reality: Always test on real devices before shipping. Emulators and simulators can’t catch everything (thermal throttling, actual memory constraints, real network conditions, etc.).

Myth 4: “Android Emulator and iOS Simulator are the same thing”

Reality: Fundamentally different approaches. One emulates, one simulates.

Practical Development Workflow

Here’s how to think about using these tools in your daily work:

For iOS Development:

1. Rapid development → iOS Simulator
   - Quick UI changes
   - Logic testing
   - Fast iteration
2. Feature testing → Real device
   - Camera features
   - ARKit
   - True performance testing
   - Hardware-specific features
3. Final testing → Multiple real devices
   - Different screen sizes
   - Different iOS versions
   - Different performance tiers

For Android Development:

1. Rapid development → Android Emulator (x86 image)
   - UI development
   - Logic testing
   - API testing
2. Feature testing → Android Emulator (ARM image) or device
   - More accurate performance
   - Hardware features
   - Different Android versions
3. Final testing → Multiple real devices
   - Different manufacturers (Samsung, Google, OnePlus, etc.)
   - Different Android skins
   - Different screen sizes and resolutions

Performance Tips

Making iOS Simulator Faster:

• Close unnecessary simulators (you can run multiple)
• Use hardware keyboard (⌘K in simulator)
• Disable unnecessary features in Xcode
• Use the latest Xcode version

Making Android Emulator Faster:

• Enable hardware acceleration (HAXM for Intel, Hypervisor for AMD)
• Use x86 system images instead of ARM when possible
• Allocate appropriate RAM (not too much, not too little)
• Use Android Studio’s emulator settings to disable animations
• Enable “Quick Boot” in AVD Manager

Debugging Differences

iOS Simulator:

- Easier to debug (native architecture)
- Xcode instruments work seamlessly
- Crashes might not match device crashes
- Memory warnings behave differently

Android Emulator:

- More accurate crashes and errors
- Can debug native (C/C++) code more reliably
- Network debugging is more representative
- Battery and thermal states can be simulated

The Memory Trap

Here’s a critical difference many of us miss:

iOS Simulator:

• Uses your Mac’s memory
• Won’t show memory constraints of actual device
• App might work fine in simulator but crash on device with limited RAM

Android Emulator:

• Can configure specific memory limits
• More representative of device constraints
• Better for testing memory-intensive apps

Example:

// This might work fine in simulator but crash on real devices
val largeList = List(1_000_000) { 
    Bitmap.createBitmap(1080, 1920, Bitmap.Config.ARGB_8888) 
}
// This uses ~8GB of memory!

When You Absolutely Need Real Devices

Some scenarios where emulators/simulators simply cannot substitute:

1. Bluetooth testing — Pairing, connection stability
2. Biometric authentication — Face ID, Touch ID, fingerprint
3. Camera features — Especially AR and ML features
4. Performance optimization — Real-world thermal throttling
5. Battery consumption — How your app affects battery life
6. Haptic feedback — Vibration and haptic engine
7. Audio latency — Music apps, games, VoIP
8. Multi-touch gestures — Complex touch interactions
9. True GPS navigation — Turn-by-turn, geofencing
10. Carrier-specific features — SMS, phone calls, cellular data

Best Practices

1. Start with simulator/emulator for rapid development

• Don’t wait for device testing during active coding
• Use them for quick iterations and UI tweaks

2. Test on real devices regularly (at least weekly)

• Don’t wait until the end to discover device-specific issues
• Keep at least one mid-range and one older device for testing

3. Understand the limitations of your testing environment

• Know what features won’t work accurately
• Document what needs real device testing

4. Use both when possible

• Simulator/emulator for speed
• Real device for accuracy

5. Automate what you can

• UI tests can run on emulators/simulators
• CI/CD pipelines can use emulator farms

The Bottom Line

Simulator (iOS):

• Fast and convenient
• Great for development
• Less accurate to real hardware
• Perfect for UI work and rapid iteration

Emulator (Android):

• More accurate than simulator
• Better hardware representation
• Slower than simulator (usually)
• Excellent for comprehensive testing

Real Device (Both):

• The ultimate truth
• Required before shipping
• Catches issues nothing else can
• Worth the investment

Moving Forward

As a mobile architect, here’s your action plan:

1. Embrace both tools → They serve different purposes
2. Budget for devices → Even one mid-range device makes a huge difference or use Firebase Test Lab
3. Document differences → Keep notes on what behaves differently
4. Ask senior devs → When in doubt about whether simulator/emulator testing is enough
5. Build good habits early → Test on real devices regularly, not just at the end

Remember: Emulators and simulators are tools in your toolbox. Like a carpenter wouldn’t use only a hammer, you shouldn’t rely solely on virtual devices. The best mobile architects know when to use each tool and understand their limitations.

Further Reading

• Apple’s iOS Simulator Documentation
• Android Emulator Guide
• Differences in Mobile Testing Environments

👏🏽 If you enjoyed this story, give it some CLAPS!

Stay in the loop for more insights on mobile development:
💡 Subscribe for upcoming articles
📚 Access free tutorials
🔔 Follow for updates

Support what we’re building at Mobterest Studio:
🤝 Join our community or contribute here
✉️ Subscribe to our newsletter for exclusive content

Can’t wait to see you in the next article! 👋

When I first encountered state management, I thought it was about choosing the right library. I assumed that if I picked the tool everyone else was using, the rest would fall into place. That belief lasted until my apps started growing and the cracks became impossible to ignore.

At the beginning of every project, things always feel manageable. There are only a few screens, data lives close to where it is used, and changes feel predictable.

I remember thinking that this was how apps were supposed to feel; simple, direct, and easy to reason about. But as features accumulated and user interactions became more layered, that simplicity faded. State began to live longer than expected. Screens depended on the same data in subtle ways. A small change in one place caused unexpected behavior somewhere else.

That was usually the moment when I reached for a state management solution, not because I had a clear strategy, but because I felt pressure to “fix” something that was starting to feel out of control.

Looking back, the issue was never the absence of a tool. The issue was that I treated state management as a reaction instead of a design decision.

Over time, I realized that state is not just a technical concern. It reflects how a product behaves, how users move through it, and how long information is expected to matter. When I stopped thinking in terms of libraries and started asking simpler questions:

• how long this data should live,
• who owns it, and
• what happens when it changes

My decisions became clearer. These were not framework questions. They were product questions, and they changed how I approached architecture entirely.

I also learned that there is no universally “best” way to manage state. What works well for a large team coordinating complex flows can feel heavy and restrictive in a small, fast-moving app.

On the other hand, approaches that feel effortless early on can become fragile when stretched beyond their limits. I’ve experienced both sides, and neither felt wrong in isolation. The problem only surfaced when the solution stopped fitting the reality of the project.

What mattered most wasn’t the tool itself, but how it shaped the way I thought. The best setups:

1. Made state changes intentional and side effects easy to follow.
2. They made debugging feel systematic instead of mysterious.
3. Most importantly, they reduced the mental effort required to understand what the app was doing at any given moment.

When a solution increased cognitive load rather than reducing it, progress slowed no matter how powerful the library was supposed to be.

In recent years, I’ve noticed a quiet shift in how experienced teams talk about state management.

The debates have softened.

Instead of arguing about which library is superior, the conversations are more grounded. They sound like, “This fits how we work,” or, “This supports how our product evolves.”

That change signals maturity. State management stops being something to fight over and becomes infrastructure; something you only notice when it’s missing or broken.

As I look toward 2026, I no longer think about state management as a future-proofing exercise.

I think about it as a present-day alignment.

The right choice is the one that respects the team you have, the product you’re building, and the pace at which change happens.

It’s the choice that lets you think clearly, move with confidence, and adapt without fear.

Everything else eventually fades into noise.

👏🏽 If you enjoyed this story, give it some CLAPS!

Stay in the loop for more insights on mobile development:
💡 Subscribe for upcoming articles
📚 Access free tutorials
🔔 Follow for updates

Support what we’re building at Mobterest Studio:
🤝 Join our community or contribute here
✉️ Subscribe to our newsletter for exclusive content

Can’t wait to see you in the next article! 👋

BLoC is often introduced as a Flutter “state management pattern.” That description is accurate, but incomplete. BLoC is less about managing state and more about managing responsibility. When understood properly, it becomes a way to design features that are predictable, testable, and easy to reason about as a product grows.

A useful way to understand BLoC is to visualize it through a real-world feature; one that most mobile products eventually need.

The Feature: User Login

At first glance, login feels simple.

A user enters credentials, taps a button, and gains access.

In reality, the feature carries several responsibilities:

• Validating user input
• Showing loading states
• Handling success and failure
• Displaying errors clearly
• Persisting authentication state

How these responsibilities are structured determines whether the feature stays manageable or slowly turns brittle.

The Naive Approach

In many early implementations, everything happens in the UI layer:

• The button triggers an API call
• The screen manages loading, success, and error states
• Business logic lives next to widgets

This works until it doesn’t. As requirements change (OTP flows, retries, biometric login) the screen becomes harder to maintain. The UI is now responsible for thinking, not just displaying.

This is the problem BLoC is designed to solve.

Thinking in BLoC Terms

BLoC stands for Business Logic Component. Its core idea is simple:

The UI should describe what happened, and the BLoC should decide what it means.

Let’s map that to the login feature.

1. Events: What Happened

Events represent user intent or system actions.

Examples:

• LoginSubmitted
• LoginRetried
• LogoutRequested

An event answers one question: What just happened?

It does not contain decisions or side effects.

2. BLoC: Where Decisions Live

The BLoC receives events and applies business rules.

For login, this includes:

• Validating credentials
• Calling the authentication service
• Mapping responses to outcomes

The BLoC does not know about buttons, screens, or layouts. It only understands inputs and rules.

Think of it as a control room that processes signals and decides the next state of the system.

3. States: What the App Looks Like Now

States describe the outcome of decisions.

Examples:

• LoginInitial
• LoginLoading
• LoginSuccess
• LoginFailure

A state answers one question: What is true right now?

The UI simply reacts to this truth.

How the UI Fits In

The UI’s role becomes clear and limited:

• Dispatch events when something happens
• Render itself based on the current state

It does not validate credentials.

It does not call APIs.

It does not decide outcomes.

This separation is what gives BLoC its strength. Each layer has one job, and that job is easy to test and reason about.

Why This Matters Beyond Code

BLoC is not just an architectural preference. It reflects product thinking.

When logic is centralized:

• Features become easier to extend
• Bugs become easier to isolate
• Teams gain confidence making changes

Most importantly, the behavior of the app becomes predictable. That predictability is what allows products to scale without fear.

The Mental Model to Keep

A useful way to visualize BLoC is this:

• Events are conversations
• The BLoC is decision-making
• States are facts
• The UI is presentation

Once that mental model clicks, BLoC stops feeling abstract. It becomes a practical tool for designing features that can grow without collapsing under their own complexity.

And that is the real value BLoC brings to a Flutter codebase.

👏🏽 If you enjoyed this story, give it some CLAPS!

Stay in the loop for more insights on mobile development:
💡 Subscribe for upcoming articles
📚 Access free tutorials
🔔 Follow for updates

Support what we’re building at Mobterest Studio:
🤝 Join our community or contribute here
✉️ Subscribe to our newsletter for exclusive content

Can’t wait to see you in the next article! 👋