Forem: Alamin Karno

How a Bug Report Led Me to Give Flutter Developers Full Control of Crisp Chat Modals on iOS

Alamin Karno — Sat, 14 Mar 2026 06:31:38 +0000

One of the things I enjoy most about maintaining open-source software is that sometimes the best improvements start with something very small.

A simple bug report.
A curious investigation.
And sometimes… a new feature idea.

This story started exactly like that.

The Bug Report That Started Everything

While reviewing issues for the Flutter Crisp Chat plugin, I noticed a report opened by Nikita Alexeev.

The title immediately caught my attention:

“Taps pass through chat modal to underlying UI on iOS 13+.”

That sounded strange.

A modal should block interactions with the UI behind it. So how could taps reach the Flutter app underneath?

I opened the issue and read the details carefully.

The behavior was simple but frustrating:

Open the Crisp chat on an iPhone
Tap near the top area of the chat
Suddenly the Flutter UI behind it reacts

Buttons could be pressed. Navigation could trigger. All while the chat was still visible.

That’s definitely not the experience anyone wants when they open a support chat.

So I started digging.

Learning Something Interesting About iOS

While reading the issue discussion and the explanation from Nikita Alexeev, I discovered something interesting about iOS.

Starting with iOS 13, Apple changed how modal presentations behave by default.

Before iOS 13, most modals were presented using:

.fullScreen

Which means the modal covers the entire screen. Nothing behind it is visible, and more importantly, nothing behind it can receive touches.

But iOS 13 introduced a new default style:

.pageSheet

This creates the modern sheet-style UI where the modal slides up from the bottom and leaves part of the background visible.

It looks elegant and more native to modern iOS design.

But there was a catch.

In this case, the dimmed background area was still allowing touch events to reach the Flutter UI underneath.

That explained exactly why users were accidentally triggering buttons behind the chat window.

Suddenly the bug made perfect sense.

The Pull Request That Fixed It

Soon after reporting the issue, Nikita Alexeev submitted a pull request with a very straightforward fix.

Instead of relying on the default modal style, he forced the chat view controller to use full screen presentation.

The change looked like this:

let chatVC = ChatViewController()
chatVC.modalPresentationStyle = .fullScreen
viewController.present(chatVC, animated: true)

It was a very small change, but it solved the problem completely.

By forcing .fullScreen, the chat now covered the entire screen again, which meant no touches could leak through to the Flutter UI behind it.

The issue was fixed.

But while reviewing the pull request, a new idea came to my mind.

The Moment the Idea Appeared

Yes, .fullScreen solved the issue.

But iOS actually supports several modal presentation styles.

For example:

.fullScreen
.pageSheet
.formSheet
.overFullScreen
.overCurrentContext
.popover

Different apps use different modal styles depending on their design.

Some apps prefer full screen.

Some prefer sheet-style modals.

Some prefer overlays.

So instead of hardcoding .fullScreen, I thought:

*What if Flutter developers could choose the modal style themselves?
*
That way:

The touch-through bug stays fixed
Developers get flexibility
The plugin becomes more powerful

That’s when the idea shifted from a bug fix to a developer-focused feature.

Turning the Idea into a Feature

To make this possible, I needed to expose the modal presentation style all the way from Flutter to the native iOS implementation.

So I started with the Flutter configuration.

Step 1 — Extending the Flutter Configuration

First, I added a new enum to represent the iOS modal styles.

enum ModalPresentationStyle {
  fullScreen,
  pageSheet,
  formSheet,
  overFullScreen,
  overCurrentContext,
  popover,
}

Then I added it to the CrispConfig class.

class CrispConfig {
  final String websiteID;
  final String? tokenId;
  final ModalPresentationStyle? modalPresentationStyle;

  CrispConfig({
    required this.websiteID,
    this.tokenId,
    this.modalPresentationStyle,
  });
}

Now Flutter developers could specify how the chat modal should appear.

Step 2 — Bridging the Setting to iOS

Next, I needed to convert that Flutter value into a native iOS presentation style.

Inside the Swift plugin code, I mapped the configuration to UIModalPresentationStyle.

switch modalPresentationStyleString {
case "fullScreen":
    modalPresentationStyle = .fullScreen
case "pageSheet":
    modalPresentationStyle = .pageSheet
case "formSheet":
    modalPresentationStyle = .formSheet
case "overFullScreen":
    modalPresentationStyle = .overFullScreen
case "overCurrentContext":
    modalPresentationStyle = .overCurrentContext
case "popover":
    modalPresentationStyle = .popover
default:
    modalPresentationStyle = .fullScreen
}

This ensured a safe default while still allowing flexibility.

Step 3 — Applying the Configuration

Finally, instead of hardcoding .fullScreen, the plugin now uses the configured style.

let chatVC = ChatViewController()
chatVC.modalPresentationStyle = crispConfig.modalPresentationStyle

viewController.present(chatVC, animated: true)

Now Flutter developers have full control over the presentation style.

Making the Feature Easy to Discover

After implementing the improvements, I wanted to make sure developers could easily explore and understand them.

So I also improved the developer experience around the plugin.

I added an interactive demo inside the example app where developers can test different iOS modal styles.

There’s a button called “iOS Modal Style Demo” that opens the chat using different presentation styles so developers can see how each one behaves.

I also updated the documentation to clearly explain:

How iOS modal presentation works
Why .fullScreen fixes the touch-through issue
How to configure the modal style in Flutter

What Developers Gain From This

What started as a small bug report now gives Flutter developers several benefits.

Better User Experience

No more accidental taps on the UI behind the chat.

Flexible Modal Presentation

Developers can choose the modal style that fits their app design.

Platform Awareness

These changes only affect iOS behavior, while Android remains unchanged.

What I Love About Open Source

This experience reminded me why I enjoy maintaining open-source projects.

Sometimes improvements don’t start with big feature ideas.

They start with a simple issue report.

A developer noticing something strange.

A pull request proposing a fix.

And a moment of curiosity that turns a bug fix into something better.

So huge thanks to Nikita Alexeev for reporting the issue and submitting the original fix that inspired this improvement.

Try It Yourself

If you’re using the Flutter Crisp Chat plugin, you can try the new configuration like this:

final config = CrispConfig(
  websiteID: 'YOUR_WEBSITE_ID',
  modalPresentationStyle: ModalPresentationStyle.pageSheet,
  enableNotifications: false,
);

And if you’re curious to see how each modal style behaves, check out the example app in the repository.

Sometimes the best features don’t start with a roadmap.

They start with a bug report…
and a little curiosity.

The Hidden Magic Behind Android’s Share Button

Alamin Karno — Tue, 27 Jan 2026 06:16:09 +0000

Have you ever hit the Share button in your app — maybe to send a funny meme, a link, or a photo — and seen that neat list of apps pop up?

As a mobile developer, I always thought it was just… magic. Call an Intent, Android shows a list, job done.

But one day, while debugging a crash on ActivityNotFoundException, I paused and asked myself:

“Wait… how does Android actually know which apps to show? How does it know WhatsApp, Gmail, or Drive can handle my data?”

That question sent me down a rabbit hole that changed how I think about app interactions forever.

Step 1: Understanding the Intent

I started with the basics. An Intent is like a messenger in Android. It carries a message from one part of the system — or even one app — to another.

There are two types of Intents:

Explicit Intents: You know exactly which component should handle your request. Example: opening your own ProfileActivity.
Implicit Intents: You only describe what you want done, not who should do it. Example: sharing an image, sending an email, or opening a PDF. Android figures out the rest.

Step 2: Breaking Down the Implicit Intent

I wrote a tiny snippet in my app:

val shareIntent = Intent().apply {
    action = Intent.ACTION_SEND
    putExtra(Intent.EXTRA_TEXT, "Check out this cool blog!")
    type = "text/plain"
}
startActivity(Intent.createChooser(shareIntent, "Share via"))

At first glance, it seems simple. But internally, it’s a beautifully orchestrated dance. Here’s what I realized:

An Implicit Intent has three main parts:

Action: What you want to do (ACTION_SEND = send something).
Category: The general type of action (CATEGORY_DEFAULT = standard).
MIME Type: What type of data you’re sending (text/plain, image/jpeg, etc.).

These three pieces of info act like a search query to find the right apps.

Step 3: The Journey of an Intent

I wanted to visualize the flow. When I tap Share, this is what happens behind the scenes:

The Intent hits the Activity Manager Service (AMS): Think of AMS as Android’s traffic controller. It decides: “Where should this message go?”
AMS asks the Package Manager Service (PMS) for matches: PMS is a database of all installed apps and their capabilities (declared via <intent-filter> in AndroidManifest.xml).
PMS matches the Intent to apps: It checks the action, category, and MIME type against every app’s intent filters. All matching apps go into a resolve list.
AMS decides what to do next: No matches? Throws ActivityNotFoundException. One match? Launches it directly. Multiple matches? Shows a chooser dialog (the familiar share sheet).

At this moment, it hit me: the share sheet is not a UI trick. It’s AMS + PMS doing intelligent matching under the hood. Mind blown.

Step 4: A Real Example — Sharing an Image

I tested sharing a photo:

val imageUri: Uri = getImageUri()
val shareIntent = Intent().apply {
    action = Intent.ACTION_SEND
    putExtra(Intent.EXTRA_STREAM, imageUri)
    type = "image/jpeg"
}
startActivity(Intent.createChooser(shareIntent, "Share Image via"))

Here’s what happens:

ACTION_SEND → I want to send something.
EXTRA_STREAM → My image URI.
type = "image/jpeg" → Only apps that can handle JPEG images appear.

The resolve list might include WhatsApp, Gmail, Drive, etc. Android doesn’t hardcode these — it calculates dynamically based on my device’s installed apps and their intent-filters.

Step 5: How Receiving Apps Register

For apps to show in the share sheet, they declare intent-filters:

<intent-filter>
    <action android:name="android.intent.action.SEND" />
    <category android:name="android.intent.category.DEFAULT" />
    <data android:mimeType="image/*" />
</intent-filter>

Action → Can handle SEND
Category → Default
Data → Any image

Android matches my Intent against this, adds it to the resolve list, and the app appears as an option. Simple in theory, elegant in execution.

Step 6: Why It Matters for Developers

This little deep dive changed how I design apps:

Better UX: I can control which apps appear by tweaking MIME types.
Graceful error handling: I now check for ActivityNotFoundException.
Powerful cross-app features: I can build apps that communicate seamlessly without hardcoding app dependencies.

It also taught me to think like Android. Every tap, every Intent, every share sheet is a tiny example of Android’s architecture at work.

Step 7: The Takeaway

Next time you tap Share, imagine the journey:

Your Intent → AMS → PMS → Resolve List → Share Sheet → Chosen App

Understanding this makes you not just a developer who “makes things work,” but a developer who understands why things work. And that perspective is invaluable.

Developer Challenge

Open your favorite app and tap Share. Ask yourself:

How is Android deciding which apps to show?
What happens if no app can handle my Intent?
How could I design my app to only show relevant options?

Curiosity leads to mastery. Start small, like I did with ACTION_SEND, and you’ll soon be exploring more complex flows like ACTION_VIEW, ACTION_PICK, and custom deep links.

Your App Worked Perfectly… Until the OS Killed It

Alamin Karno — Fri, 23 Jan 2026 20:12:16 +0000

A production story from real apps. For a long time, I thought process death was an edge case. Something you read about in docs. Something that might happen, but not in real life. After all, my apps worked fine. QA was happy. Users were using them.

Then production taught me otherwise.

It Started With Autonemo

While working on Autonemo, a vehicle tracking app, everything looked solid:

Live vehicle tracking
Trip status
Ongoing routes
Driver activity

You open the app → tracking works.
You background it → come back → still works.

Until users started reporting something strange:

“Sometimes when I come back to the app, tracking is gone.”
“The trip looks like it never started.”

No crashes.
No ANRs.
No error logs.

Just… wrong state.

The Bug I Couldn’t Reproduce

On my phone:

High RAM
Latest Android
No aggressive background killing

I could switch apps, come back, and everything was fine.

But real users?

Budget devices
Old OS versions
Heavy multitasking

That’s when I realized:

The OS was killing the app in the background.

Not pausing it. Not stopping it nicely.
Killing the process.

The Mistake (Flutter)

At that time, critical tracking state lived only in memory:

class TrackingState {
  bool isTripActive = false;
  String? vehicleId;
}

As long as the app was alive:

UI was correct
Tracking looked accurate

But once the OS killed the process:

Memory was wiped
State reset
App restarted as if nothing was happening

No crash = no alert.
Just broken logic.

“Okay, Fixed” — Then VivaUtilities Happened

Later, while working on VivaUtilities, a Flutter app for meal and leave management, I saw the same issue — but this time in a different form.

Users would:

Start applying for leave
Fill half the form
Switch apps (email, calendar, messages)
Come back…

And the form was empty.

Again:

No crash
No error
Just lost progress

And again, QA couldn’t reproduce it consistently.

The Common Pattern I Missed

I finally stopped looking at features and started looking at lifecycle.

Both apps had the same assumption:

“If the app goes to background, my state is still there.”

That assumption is wrong.

On Flutter:

Widgets rebuild
Controllers recreate
Providers restart

If the process is dead, everything in memory is gone.

The Flutter Fix: Persist What Matters

I changed how I decided what to persist.

Not everything. Only what would hurt to lose.

await prefs.setBool('is_trip_active', true);
await prefs.setString('vehicle_id', vehicleId);

Then restored it on app start, not later.

For UI-related state, I also started using state restoration (which I had ignored before):

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

  @override
  State<LeaveFormScreen> createState() => _LeaveFormScreenState();
}

class _LeaveFormScreenState extends State<LeaveFormScreen>
    with RestorationMixin {

  final RestorableString reason = RestorableString('');

  @override
  String get restorationId => 'leave_form';

  @override
  void restoreState(RestorationBucket? oldBucket, bool initialRestore) {
    registerForRestoration(reason, 'leave_reason');
  }
}

This alone prevented a whole class of “random reset” complaints.

Then Native Android Taught Me the Same Lesson (VivaCash)

I thought this was a Flutter-specific problem.

Then VivaCash proved me wrong.

VivaCash is a native Android app written in Java, handling sensitive MFS flows:

Amount input
Transaction steps
OTP flows
App switching (SMS, banking apps)

Users reported:

“I went to check OTP and came back — transaction restarted.”

Again:

No crash
No exception
Just lost state

The Java Trap: Trusting Memory Too Much

The code looked innocent:

public class PaymentViewModel extends ViewModel {
    public double amount = 0.0;
}

I assumed:

“ViewModel survives rotation, so I’m safe.”

But ViewModel does not survive process death.

When the OS killed the app:

ViewModel was recreated
Amount reset
Flow broken

The Real Fix on Android: `SavedStateHandle`

Once we moved critical state into SavedStateHandle, the issue disappeared:

public class PaymentViewModel extends ViewModel {

    private SavedStateHandle handle;

    public PaymentViewModel(SavedStateHandle handle) {
        this.handle = handle;
    }

    public void setAmount(double amount) {
        handle.set("amount", amount);
    }

    public double getAmount() {
        Double value = handle.get("amount");
        return value != null ? value : 0.0;
    }
}

Now:

Rotation → safe
Background kill → safe
Process recreation → safe

The Rule I Ship Apps With Now

After Autonemo. After VivaUtilities. After VivaCash.

This is the rule I never break:

If losing it would confuse or frustrate the user, it does not belong only in memory.

Memory is temporary. The OS is ruthless. Users don’t care why it happened.

Why This Bug Is So Dangerous

It passes QA
It doesn’t crash
It only happens on real devices
It slowly destroys trust

And users don’t complain loudly. They just stop using your app.

Final Thought

Your app doesn’t fail when it crashes.

It fails when the OS kills it — and your app pretends nothing important was happening.

That’s a silent failure. And those are the worst ones.

That One Share Button That Broke on iOS 26 and How I Fixed It

Alamin Karno — Wed, 17 Dec 2025 20:53:25 +0000

A few weeks ago, during my holiday break, I decided to revisit one of my old pet projects WallpaperHub. It’s a simple Flutter app where users can browse wallpapers and share them with friends.

Nothing fancy.
Nothing experimental.

Or at least… that’s what I thought.

The Calm Before the Crash

The app had been running perfectly for a long time.

Flutter app ✅
share_plus plugin ✅
Tested on iOS 17 ✅
Tested on Android ✅

I recently updated my system and got access to an iOS 26 device.
Naturally, I wanted to run the app and see how it behaves on the latest iOS.

The app launched.
The UI looked fine.
Scrolling was smooth.

Then I tapped the Share button.

💥 Boom. Runtime exception.

“Wait… This Worked Yesterday”

The crash happened only when triggering the share action.

What confused me even more:

Same code
Same plugin version
Same app
Worked perfectly on iOS 17

But on iOS 26, the app crashed immediately.

At first, I assumed:

Maybe Xcode issue
Maybe simulator bug
Maybe iOS beta instability

But no, this was a real breaking change.

The Error That Gave It Away

After carefully reading the logs, the issue pointed toward the share sheet presentation on iOS.

That’s when I remembered something important:

On iOS, sharing content requires a valid source rectangle for popover presentation.

Older iOS versions were more forgiving.
iOS 26? Not anymore.

The Root Cause (Why This Happens)

If you’re using share_plus version 11 or below, the plugin internally relied on deprecated behavior when presenting the iOS share sheet.

Specifically:

iOS now strictly requires a valid sharePositionOrigin
Without it, the app crashes at runtime
Older iOS versions silently ignored this

So, upgrading iOS exposed an incompatibility in older plugin versions.

This wasn’t a Flutter issue.
This wasn’t my code logic issue.
It was an outdated dependency.

The Quick Fix (Two Ways)

Still Using Deprecated Code? It Won’t Break (Yet)

Interestingly, even in the latest versions, deprecated APIs still work, as long as you explicitly provide the required positioning.

Here’s the updated code I used in my app:

final box = context.findRenderObject() as RenderBox?;

return SharePlus.instance.share(
  ShareParams(
    text: text,
    title: title,
    subject: subject,
    sharePositionOrigin:
        box!.localToGlobal(Offset.zero) & box.size, // REQUIRED for iOS
  ),
);

This single line is the key

box!.localToGlobal(Offset.zero) & box.size

It tells iOS:

“Here’s where the share sheet should originate from.”

Without it, 💥 crash.

Real Example From My Project

This wasn’t a demo fix.
This is exactly what I did in my real project WallpaperHub.

GitHub repo: 👉 https://github.com/alamin-karno/wallpaper_hub
Exact file where the fix lives: 👉 https://raw.githubusercontent.com/alamin-karno/wallpaper_hub/refs/heads/master/lib/core/helper/app_helper.dart

If you open that file, you’ll see how the helper method safely handles sharing across platforms including iOS 26.

Why iOS 26 Made This Visible

This is the important takeaway

iOS 26 didn’t break your app.
It stopped tolerating unsafe behavior.

Older iOS versions:

Allowed missing share origin
Failed silently

iOS 26:

Enforces correct popover positioning
Crashes if you don’t provide it

This is actually a good thing but only if your dependencies are up to date.

Lessons Learned (So You Don’t Suffer Like I Did)

Always test your Flutter apps on the latest iOS
Old plugins can break even if your code hasn’t changed
iOS is less forgiving with UI presentation rules
Reading logs carefully saves hours
Sometimes… AI really does help

Final Thoughts

This bug cost me a few hours of digging, log reading, and head scratching all from tapping a single Share button.

But that’s Flutter life:

One OS update
One outdated plugin
One runtime crash

Hopefully, this story saves you that time.

If your Flutter app crashes on iOS 26 when sharing, now you know exactly why and how to fix it.

Happy coding 🚀 And keep your dependencies fresh.