Question 1

How do you handle permissions in Flutter?

Accepted Answer

I handle all three states: granted — run the feature; denied — explain why it is needed and ask again; permanentlyDenied — the system dialog will never reappear, so show a button that opens settings. That last case is the one most often missed, and to the user it feels like a broken button. I would stress the UX too: I ask at the moment of need with a short rationale first, never at launch, because an out-of-context dialog sharply raises refusals. On the platform side: the Android manifest and the iOS Info.plist usage string — without that string iOS crashes on request.

Question 2

How should the app behave if the user refuses a permission?

Accepted Answer

The principle: the app must keep working, with only that feature unavailable. Blocking the screen or closing the app is bad practice. Concretely: a clear message explaining why the feature is unavailable, an alternative path where one exists (picking from the gallery or entering data by hand instead of scanning), and an obvious way to grant the permission later. One more point: respect the refusal — re-asking on every launch annoys users and, in some stores, counts as a policy violation.

Question 3

How would you improve permission acceptance rates?

Accepted Answer

The pre-permission pattern: show your own explanation screen before the system dialog — why it is needed and what the user gains. The system dialog is terse and unchangeable; your screen supplies the context. The second factor is timing: after the user taps "Scan document", a camera prompt makes sense; on the first screen of the app it looks suspicious. Third, ask only for what you need — bundling several requests erodes trust. I would add measurement: track acceptance in analytics and A/B test the rationale copy, so the decision rests on data rather than assumption.

State	Meaning	Correct behaviour
granted	Permission granted	Proceed with the feature
denied	Refused, but you may ask again	Explain why it is needed and ask again
permanentlyDenied	The user chose not to be asked again	Show a button that opens system settings
restricted	Blocked by device policy such as parental controls	Offer an alternative; do not keep asking

Permissions and device capabilities

📚 Sources and documentation