DEV Community: NERDZ LAB

How to Connect Google Analytics to Claude

NERDZ LAB — Mon, 29 Jun 2026 16:37:12 +0000

A step-by-step guide. Two files to copy, one command to run!

If you use Google Analytics to track your website, there is a way to stop opening dashboards and just ask Claude questions instead.

“How many people visited my site last week?”
“What are my most read pages this month?”
“Which country sends me the most traffic?”
Claude will fetch the real numbers and answer you directly.

Here is everything you need to set it up!

What you will need before you start

→ A Google Analytics account (the current version, called GA4)

→ A Google account that has access to that Analytics property

→ Claude Cowork installed on your computer (or Claude Code)

→ Python installed on your computer (free — download from python.org if needed)

Step 1 — Create a read-only access pass for Claude

Think of this step as creating a special key that lets Claude read your analytics data — but nothing else. It cannot change anything, it cannot delete anything. Read only.

Open your browser and go to: console.cloud.google.com Sign in with the same Google account you use for Analytics.
At the top of the page, click the project dropdown (it may say “Select a project”). Click New Project → give it any name (e.g. “My Analytics”) → click Create. Wait a few seconds, then select your new project from the dropdown.
In the search bar at the top, type: Google Analytics Data API. Click the result → click the blue Enable button.
In the left menu, click IAM & Admin → Service Accounts → + Create Service Account. In the name field, type anything — for example: claude-analytics-reader. Click Create and Continue → skip the next two steps → Done.
You will now see your new account listed. Click on it. Go to the Keys tab → Add Key → Create new key → select JSON → click Create. A file will download to your computer. This is your access key — keep it safe. Also copy the email address shown for this account: claude-analytics-reader@your-project-name.iam.gserviceaccount.com – you will need this email in the next step.

Step 2 — Give that access pass permission to see your analytics

The key from Step 1 exists, but Google Analytics doesn’t know about it yet. You need to invite it.

Go to: analytics.google.com
Click the gear icon (⚙️) at the bottom left → this opens Admin settings.
In the middle column (Property), click Property Access Management.
Click the + button (top right) → Add users. Paste in the email address from Step 1. Set the role to Viewer. Uncheck “Notify new users by email” (it’s not a real inbox). Click Add.
While still in Admin, click Property Settings (middle column). Find the Property ID — it is a plain number, like 123456789. Write this number down. You will need it in Step 4.

Step 3 — Install one software package

Open the Terminal app on your computer. (On Mac: press Cmd + Space, type Terminal, press Enter. On Windows: press the Windows key, type cmd, press Enter.)

Type the following and press Enter:

pip3 install google-analytics-data –break-system-packages

Wait until you see “Successfully installed”. That is all for this step.

(The –break-system-packages part is required on modern Mac and Linux computers. It just tells the installer to go ahead — it is safe.)

Step 4 — Create a folder and add three files

On your computer, navigate to this folder:

Mac/Linux: the folder called .claude/skills/ inside your home folder
Windows: *C:\Users\YourName.claude\skills*

If the skills folder does not exist yet, create it.

Inside that folder, create a new folder called: google-analytics. Move the key file you downloaded in Step 1 into this folder. Rename that file to: your-credentials.json

Inside the google-analytics folder, create two new text files. Copy the contents below exactly into each one. Your folder should look like this when done:

.claude/skills/google-analytics/
├── SKILL.md ← copy content from File 1 below
├── query_script.py ← copy content from File 2 below
└── your-credentials.json ← the key file from Step 1

File 1 — Copy this into a file named: SKILL.md

—
name: google-analytics
description: “Query Google Analytics 4 data. Use when the user asks about website traffic, page views, sessions, user counts, conversions, top pages, traffic sources, or any analytics/metrics questions. Trigger on keywords like \”analytics\”, \”traffic\”, \”visitors\”, \”page views\”, \”sessions\”, \”GA4\”, \”bounce rate\”, \”conversions\”, \”top pages\”, \”referrals\”.”
metadata:
version: 1.0.0
—
# Google Analytics 4 Skill
Query GA4 property data using the Google Analytics Data API v1.
## Setup
– **Credentials**: Service account JSON key — place it in the same folder as query_script.py with the filename your-credentials.json. The script resolves the path automatically.
– **Property ID**: 123456789
– **Python dependency**: google-analytics-data (install: pip3 install google-analytics-data –break-system-packages)
## How to Use
Run the query script using its absolute path:
python3 ~/.claude/skills/google-analytics/query_script.py –report <report_type> [options]
The credentials file is resolved automatically from the same directory as the script.
## Available Reports
overview — High-level summary: users, sessions, page views, bounce rate, engagement rate
pages — Top pages by views, with users and avg engagement time
sources — Traffic by source and medium, sessions, conversions
countries — Geographic breakdown: country, sessions, users, engagement rate
devices — Desktop / mobile / tablet split
daily — Day-by-day trend: date, users, sessions, page views
realtime — Active users on the site right now
custom — Any GA4 metric and dimension combination
## Common Options
–days N How many days to look back (default: 30)
–limit N Maximum number of rows to return (default: 10)
–start DATE Exact start date in format YYYY-MM-DD
–end DATE Exact end date in format YYYY-MM-DD
–output Output format: table, json, or csv
## Example Commands
python3 query_script.py –report overview –days 7
python3 query_script.py –report pages –days 30 –limit 20
python3 query_script.py –report sources –days 30
python3 query_script.py –report daily –days 14
python3 query_script.py –report realtime
—

File 2 — Copy this into a file named: query_script.py

Before copying, find the two lines near the top marked CHANGE THIS and update them:

→ Replace your-credentials.json with the actual filename of your key file (if you renamed it differently)

→ Replace 123456789 with your own Property ID from Step 2

#!/usr/bin/env python3
“””
Google Analytics 4 Data API query tool.
Queries GA4 property data using a service account.
“””
import argparse
import json
import sys
import os
from datetime import datetime, timedelta
# ============================================================
# CHANGE THIS — update the two values below to match your setup
# ============================================================
CREDENTIALS_PATH = os.path.join(os.path.dirname(os.path.abspath(__file__)), “your-credentials.json”)
PROPERTY_ID = “123456789”
# ============================================================
def get_client():
“””Create and return a GA4 BetaAnalyticsDataClient.”””
os.environ[“GOOGLE_APPLICATION_CREDENTIALS”] = CREDENTIALS_PATH
from google.analytics.data_v1beta import BetaAnalyticsDataClient
return BetaAnalyticsDataClient()
def build_request(metrics, dimensions, days=30, start=None, end=None, limit=10, order_by_metric=None, desc=True):
“””Build a RunReportRequest.”””
from google.analytics.data_v1beta.types import (
RunReportRequest, Metric, Dimension, DateRange, OrderBy
)
end_date = end or datetime.now().strftime(“%Y-%m-%d”)
if start:
start_date = start
else:
start_date = (datetime.now() – timedelta(days=days)).strftime(“%Y-%m-%d”)
request = RunReportRequest(
property=f”properties/{PROPERTY_ID}”,
metrics=[Metric(name=m.strip()) for m in metrics],
dimensions=[Dimension(name=d.strip()) for d in dimensions] if dimensions else [],
date_ranges=[DateRange(start_date=start_date, end_date=end_date)],
limit=limit,
)
if order_by_metric:
request.order_bys = [
OrderBy(
metric=OrderBy.MetricOrderBy(metric_name=order_by_metric),
desc=desc,
)
]
return request
def format_response(response, output=”table”):
“””Format the API response into the desired output format.”””
headers = [h.name for h in response.dimension_headers] + [h.name for h in response.metric_headers]
rows = []
for row in response.rows:
values = [dv.value for dv in row.dimension_values] + [mv.value for mv in row.metric_values]
rows.append(values)
if output == “json”:
result = []
for row in rows:
result.append(dict(zip(headers, row)))
return json.dumps(result, indent=2)
elif output == “csv”:
lines = [“,”.join(headers)]
for row in rows:
lines.append(“,”.join(row))
return “\n”.join(lines)
else: # table
col_widths = [len(h) for h in headers]
for row in rows:
for i, val in enumerate(row):
col_widths[i] = max(col_widths[i], len(str(val)))
separator = “+” + “+”.join(“-” * (w + 2) for w in col_widths) + “+”
header_row = “|” + “|”.join(f” {h:<{col_widths[i]}} ” for i, h in enumerate(headers)) + “|”
lines = [separator, header_row, separator]
for row in rows:
line = “|” + “|”.join(f” {str(v):<{col_widths[i]}} ” for i, v in enumerate(row)) + “|”
lines.append(line)
lines.append(separator)
if response.row_count:
lines.append(f”\nTotal rows: {response.row_count}”)
return “\n”.join(lines)
def report_overview(client, args):
“””High-level site overview.”””
request = build_request(
metrics=[“totalUsers”, “newUsers”, “sessions”, “screenPageViews”,
“averageSessionDuration”, “engagementRate”, “bounceRate”],
dimensions=[],
days=args.days, start=args.start, end=args.end, limit=1,
)
response = client.run_report(request)
return format_response(response, args.output)
def report_pages(client, args):
“””Top pages by views.”””
request = build_request(
metrics=[“screenPageViews”, “totalUsers”, “averageSessionDuration”],
dimensions=[“pagePath”, “pageTitle”],
days=args.days, start=args.start, end=args.end, limit=args.limit,
order_by_metric=”screenPageViews”,
)
response = client.run_report(request)
return format_response(response, args.output)
def report_sources(client, args):
“””Traffic sources.”””
request = build_request(
metrics=[“sessions”, “totalUsers”, “engagementRate”, “conversions”],
dimensions=[“sessionSource”, “sessionMedium”],
days=args.days, start=args.start, end=args.end, limit=args.limit,
order_by_metric=”sessions”,
)
response = client.run_report(request)
return format_response(response, args.output)
def report_countries(client, args):
“””Geographic breakdown.”””
request = build_request(
metrics=[“sessions”, “totalUsers”, “engagementRate”],
dimensions=[“country”],
days=args.days, start=args.start, end=args.end, limit=args.limit,
order_by_metric=”sessions”,
)
response = client.run_report(request)
return format_response(response, args.output)
def report_devices(client, args):
“””Device category breakdown.”””
request = build_request(
metrics=[“sessions”, “totalUsers”, “engagementRate”],
dimensions=[“deviceCategory”],
days=args.days, start=args.start, end=args.end, limit=args.limit,
order_by_metric=”sessions”,
)
response = client.run_report(request)
return format_response(response, args.output)
def report_daily(client, args):
“””Day-by-day trend.”””
request = build_request(
metrics=[“totalUsers”, “sessions”, “screenPageViews”],
dimensions=[“date”],
days=args.days, start=args.start, end=args.end, limit=args.days or 30,
)
from google.analytics.data_v1beta.types import OrderBy
request.order_bys = [
OrderBy(dimension=OrderBy.DimensionOrderBy(dimension_name=”date”), desc=False)
]
response = client.run_report(request)
return format_response(response, args.output)
def report_realtime(client, args):
“””Realtime active users.”””
from google.analytics.data_v1beta.types import (
RunRealtimeReportRequest, Metric, Dimension
)
request = RunRealtimeReportRequest(
property=f”properties/{PROPERTY_ID}”,
metrics=[Metric(name=”activeUsers”)],
dimensions=[Dimension(name=”unifiedScreenName”)],
limit=args.limit,
)
response = client.run_realtime_report(request)
headers = [h.name for h in response.dimension_headers] + [h.name for h in response.metric_headers]
rows = []
for row in response.rows:
values = [dv.value for dv in row.dimension_values] + [mv.value for mv in row.metric_values]
rows.append(values)
if not rows:
return “No active users right now.”
if args.output == “json”:
result = [dict(zip(headers, row)) for row in rows]
return json.dumps(result, indent=2)
elif args.output == “csv”:
lines = [“,”.join(headers)]
for row in rows:
lines.append(“,”.join(row))
return “\n”.join(lines)
else:
col_widths = [len(h) for h in headers]
for row in rows:
for i, val in enumerate(row):
col_widths[i] = max(col_widths[i], len(str(val)))
separator = “+” + “+”.join(“-” * (w + 2) for w in col_widths) + “+”
header_row = “|” + “|”.join(f” {h:<{col_widths[i]}} ” for i, h in enumerate(headers)) + “|”
lines = [separator, header_row, separator]
for row in rows:
line = “|” + “|”.join(f” {str(v):<{col_widths[i]}} ” for i, v in enumerate(row)) + “|”
lines.append(line)
lines.append(separator)
return “\n”.join(lines)
def report_custom(client, args):
“””Custom query with user-specified metrics and dimensions.”””
if not args.metrics:
return “Error: –metrics required for custom report (comma-separated)”
metrics = [m.strip() for m in args.metrics.split(“,”)]
dimensions = [d.strip() for d in args.dimensions.split(“,”)] if args.dimensions else []
request = build_request(
metrics=metrics,
dimensions=dimensions,
days=args.days, start=args.start, end=args.end, limit=args.limit,
order_by_metric=metrics[0],
)
response = client.run_report(request)
return format_response(response, args.output)
REPORTS = {
“overview”: report_overview,
“pages”: report_pages,
“sources”: report_sources,
“countries”: report_countries,
“devices”: report_devices,
“daily”: report_daily,
“realtime”: report_realtime,
“custom”: report_custom,
}
def main():
parser = argparse.ArgumentParser(description=”Query Google Analytics 4 data”)
parser.add_argument(“–report”, required=True, choices=REPORTS.keys(), help=”Report type”)
parser.add_argument(“–days”, type=int, default=30, help=”Lookback period in days (default: 30)”)
parser.add_argument(“–start”, help=”Start date (YYYY-MM-DD), overrides –days”)
parser.add_argument(“–end”, help=”End date (YYYY-MM-DD), defaults to today”)
parser.add_argument(“–limit”, type=int, default=10, help=”Max rows (default: 10)”)
parser.add_argument(“–output”, choices=[“table”, “json”, “csv”], default=”table”, help=”Output format”)
parser.add_argument(“–metrics”, help=”Comma-separated metrics (for custom report)”)
parser.add_argument(“–dimensions”, help=”Comma-separated dimensions (for custom report)”)
args = parser.parse_args()
try:
client = get_client()
result = REPORTS[args.report](client, args)
print(result)
except Exception as e:
print(f”Error: {e}”, file=sys.stderr)
sys.exit(1)
if __name__ == “__main__”:
main()

Step 5 — Test that it works

Open your Terminal again. Type the following and press Enter:

python3 ~/.claude/skills/google-analytics/query_script.py –report overview –days 7

If you see a table with numbers, you are done. Those are your real analytics numbers. If you see an error, check the common fixes at the bottom of this article.

Step 6 — Ask Claude

Open Claude Cowork. Type any of these questions naturally:

“How much traffic did my site get this week?”
“What are my top pages in the last 30 days?”
“Where is my traffic coming from?”
“Show me a daily breakdown of visitors this month”
“How many people are on my site right now?”

Claude will run the script automatically, pull your real data, and answer you. Available report types you can ask about:

→ Overview (total users, sessions, bounce rate)

→ Top pages

→ Traffic sources

→ Countries

→ Devices (desktop vs mobile)

→ Daily trends

→ Realtime (who is on your site right now)

If something goes wrong

“Permission denied” or “403 error”

→ You skipped or made a mistake in Step 2. Go back and make sure the service account email is added as a Viewer in your Analytics settings.

“No module named google”

→ The package from Step 3 didn’t install properly. Run the pip3 install command again.

“Property not found”

→ Your Property ID in query_script.py has a typo. It should be just the number (e.g. 123456789), nothing else.

“Claude doesn’t understand my question”

→ Try being specific: “Use the google-analytics skill to show me traffic for the last 7 days.”

Find more insights on our website

Reverse Engineering a Flutter App: How Secure Is Your Data, Really?

NERDZ LAB — Fri, 12 Jun 2026 12:23:42 +0000

A hands-on walkthrough of Flutter APK static analysis, AOT snapshot decompilation with B(l)utter, and the prevention techniques that actually hold up in production.

Have you ever asked yourself whether the .env file, API keys, or premium content inside your Flutter app are actually safe — or just assumed to be? Most teams treat the compiled APK as a black box. It is not. With a laptop and a couple of open-source tools, a reverse engineer can pull strings, function addresses, class layouts, and hardcoded secrets out of a release Flutter build in minutes.

This article walks through what a Flutter app looks like from a reverse engineering perspective: what an attacker can read straight out of an APK without decompiling anything, what they pull out of libapp.so once they do, and — most importantly — which prevention techniques actually work. The findings below come from third-party production apps we reverse-engineered as part of independent security research — not apps we built. One of them is a banking app with more than one million downloads that we discovered was leaking sensitive keys in plain text.

What you will learn

How to perform static analysis on a Flutter APK without decompilation
How Dart code is compiled in debug vs release mode (JIT vs AOT) and why it matters for security
How to decompile a Flutter release build with B(l)utter and read the AOT snapshot
What Flutter’s –obfuscate flag actually protects (and what it does not)
Practical strategies to protect API keys, assets, and local data in a Flutter app

Static analysis of a Flutter APK without decompilation

Static analysis is the process of inspecting an app’s files without running the code. For a Flutter app, you do not need to understand the Flutter internals to start. A free tool called apktool unpacks an APK into its raw components — resources, manifests, and native libraries — and that alone can reveal a surprising amount of data that developers assume is safely hidden inside the binary.

Unpacking the APK
Once you have an APK from a build server or extracted from a device, the command is:

apktool d suspect.apk

In our case, for the purposes of this walkthrough, we are working with a sample APK we built from source ourselves, so no extraction step is needed. If you want to pull an APK from an installed app on a real device, you can extract it first with adb. Unpacking produces a folder of resources and code. The main areas of interest for static analysis:

AndroidManifest.xml — can contain hardcoded API keys. A classic example is Google Maps:

<meta-data android:name="com.google.android.geo.API_KEY" 
android:value="key"/>

assets/ — may include animations, images, hardcoded .tflite ML models, or environment files.
res/strings.xml — often contains interesting strings and configuration values.

A real-world finding: the flutter_dotenv leak
One of the most striking finds from our reverse engineering research was a .env file shipped inside the assets of a third-party banking app with more than one million downloads. We did not build this app — we only analysed it from the outside, the same way any attacker could. It contained sensitive keys that were never meant to be public, and the cause was a single mistake by the app’s original developers: they used flutter_dotenv and ignored its own documentation warning:

Values loaded by this package should be treated as public client-side configuration.

In other words: anything that ends up in an asset bundle is public, period. The package can be useful for non-secret runtime configuration, but it should never be used to hide credentials.

Local app data and rooted devices
Another common assumption is that data stored in an app’s private folder (/data/data//) is safe. That is true — on a non-rooted device. On a rooted device, Android’s sandbox restrictions do not apply the same way, and anyone with root access can pull the entire data directory using standard adb tools:

adb root
adb pull /data/data/com.example.app/ ./app_data/

This captures cached files, SQLite databases, shared preferences — including any “locked” or premium content you assumed was protected by the file system.

There is a whole catalogue of static analysis techniques and prevention strategies in the OWASP Mobile Application Security project, which is the de facto reference for what to test and how to defend against it.

How Flutter compiles your app (JIT vs AOT)

Before decompiling anything, it helps to understand how Dart code becomes the binary that ships in your APK. Flutter has two fundamentally different compile pipelines depending on the build mode.

In debug mode, the Dart frontend compiler transforms your source into a Kernel AST — a high-level intermediate representation that gets JIT-compiled on the device at runtime. Recovering near-original source from a debug APK is straightforward.

In release mode, your code goes through AOT compilation: the compiler performs program analysis, tree-shakes dead code, and produces an AOT snapshot — native machine code plus a pre-built heap image containing all the objects your program needs (string literals, constants, type metadata). This snapshot is packaged as libapp.so.

The other native library, libflutter.so, is the Flutter engine itself — a prebuilt C/C++ shared library containing the Dart VM runtime, the rendering engine, and the platform embedding layer.

How it all comes together at runtime
When the app launches, the system loads libflutter.so (the engine), which then loads libapp.so (your compiled Dart code). The engine maps the snapshot’s data — all the pre-built objects like strings, constants, and type info — directly into memory as part of the Dart heap. From that point on, the compiled machine code in libapp.so executes and references those heap objects as needed.

The practical consequence: every string literal, constant, and type identifier in your release app exists in a structured, addressable region of memory — and on disk. That region is exactly what reverse engineering tools target.

Decompiling a Flutter app with B(l)utter

With a debug APK, you can recover something very close to the original source code thanks to the Kernel AST. But that is rarely what you find in the wild — most apps ship release builds compiled through AOT, and the picture there is very different.

Flutter is constantly evolving, and there is no single universal decompiler because the snapshot format changes between Dart SDK versions. Many older tools are now abandoned. The two that currently work with recent Flutter versions are reFlutter and B(l)utter — the latter is the one we use here.

Setting up: extracting libapp.so and libflutter.so
B(l)utter currently supports the arm64-v8a architecture only. The two libraries you need are inside the unpacked APK:

lib/
└── arm64-v8a/
     ├── libapp.so
     └── libflutter.so

Then run the tool:

python3 blutter.py lib/arm64-v8a output_directory

B(l)utter will download the necessary Dart SDK components on its own and start decompilation. The output looks like this:

output_directory/
├── asm/      - app code in assembler
├── objs.txt  - dart objects
└── pp.txt    - object pool

Reading the object pool: every hardcoded string, exposed
pp.txt contains everything that was hardcoded — API URLs, keys, system data. You can run any secrets-scanning tool against this file and find anything that was not properly handled. objs.txt contains a different representation: a raw dump of Dart objects rather than pool references.

Reading the assembler: function structure with original names
If you are interested in the actual code, look inside asm/. Every library, the Flutter framework itself, and the full source code structure — including original naming from development — is there, in assembler. If the app is not obfuscated, a class containing a terms link looks like this in the decompiled output:

static Uri termsLink() {
   // ** addr: 0x8fcc2c, size: 0x38
   // 0x8fcc2c: EnterFrame
   //     0x8fcc2c: stp             fp, lr, [SP, #-0x10]!
   //     0x8fcc30: mov             fp, SP
   // 0x8fcc34: CheckStackOverflow
   //     0x8fcc34: ldr             x16, [THR, #0x48]  ; 
THR::stack_limit
   //     0x8fcc38: cmp             SP, x16
   //     0x8fcc3c: b.ls            #0x8fcc5c
   // 0x8fcc40: r1 = "https://app.com/terms"
   //     0x8fcc40: add             x1, PP, #0x25, lsl #12  ; 
[pp+0x25980] "https://app.com/terms"
   //     0x8fcc44: ldr             x1, [x1, #0x980]
   // 0x8fcc48: r4 = const [0, 0x1, 0, 0x1, null]
   //     0x8fcc48: ldr             x4, [PP, #0x358]  ; 
[pp+0x358] List(5) [0, 0x1, 0, 0x1, Null]
   // 0x8fcc4c: r0 = parse()
   //     0x8fcc4c: bl              #0x4cb1c4  ; 
[dart:core] Uri::parse
   // 0x8fcc50: LeaveFrame
   //     0x8fcc50: mov             SP, fp
   //     0x8fcc54: ldp             fp, lr, [SP], #0x10
   // 0x8fcc58: ret
   //     0x8fcc58: ret
   // 0x8fcc5c: r0 = StackOverflowSharedWithoutFPURegs()
   //     0x8fcc5c: bl              #0xbea960  ; 
StackOverflowSharedWithoutFPURegsStub
   // 0x8fcc60: b               #0x8fcc40
}

That is a lot of assembler. The corresponding Dart source is just four lines:

static final Uri termsLink = Uri.parse(
   'https://app.com/terms',
);

The PP register and the object pool, in practice
This example also shows how compiled Dart accesses the object pool. It uses the PP register — a dedicated CPU register that points to the current function’s object pool — and loads data from a specific offset:

// 0x8fcc40: r1 = "https://app.com/terms"
//     0x8fcc40: add             x1, PP, #0x25, lsl #12  ; 
[pp+0x25980]
//     0x8fcc44: ldr             x1, [x1, #0x980]

And in pp.txt the same string appears at exactly that offset:

[pp+0x25980] String: "https://app.com/terms"

What obfuscation looks like
If the app is built with obfuscation enabled, class and field names are replaced with meaningless identifiers. The code still references objects from the object pool the same way:

// class id: 251, size: 0x18, field offset: 0x8
class Ooa extends Object {
late int _uEd; // offset: 0x14
late double _rEd; // offset: 0x8
late double _sEd; // offset: 0xc
late double _tEd; // offset: 0x10
}

Why this matters: Frida and runtime hooks
With the structure laid out — function addresses, class layouts, field offsets — the next step for an attacker is dynamic instrumentation. Tools like Frida attach to a running process and modify behaviour at runtime. The decompiled output gives them every address they need.

This is why hardcoding secrets, relying on client-side checks, or assuming obfuscation is enough are all dangerous assumptions. Once someone has libapp.so, the object pool gives them every string, and the assembly gives them every function address. Obfuscation raises the effort but does not change the outcome — the structure is still there, and tools like B(l)utter make it accessible.

Reverse Engineering a Flutter App: How Secure Is Your Data, Really?

Prevention — what actually protects a Flutter app

The defences below are ordered by impact. The first three address the data itself. The last three address the environment the app runs in.

1. API keys: do not put them in the client
API keys can be injected at build time through build.gradle (Android) or Info.plist (iOS) using secrets files. This avoids checking keys into source control — but the keys still end up as strings inside the binary, and the object pool still exposes them.

The truly secure approach is to never put sensitive keys in the client at all. Use a backend proxy that holds the credentials server-side and exposes only authenticated, scoped endpoints to your app. Where a key absolutely has to ship with the client (some third-party SDKs require it), use the provider’s key-restriction features: bind the key to your app’s signing certificate, package name, and bundle ID.

2. Assets: encrypt, and deliver the key from the server
Protecting bundled assets — premium content, ML models, media — is harder because there is no equivalent of a backend proxy. The only real option is encryption. But the decryption key itself becomes the new problem: if it is hardcoded in the app, you are back to square one.

The stronger approach is to deliver decryption keys from the server only after the user has been authenticated and a purchase has been verified. The encrypted asset can ship with the app; the key never does.

3. envied: useful, not bulletproof
The envied package adds a layer of obfuscation to compiled-in values. It makes secrets harder to spot in a casual scan of the binary, but it does not encrypt them and does not change the underlying fact that the values live in the object pool. Treat it as friction, not as a security control.

4. Always build with –obfuscate and –split-debug-info
For release builds, always pass the obfuscation flags:

flutter build apk --obfuscate --split-debug-info=debug-info/

This is a baseline hardening step that costs nothing. But — and this is critical — –obfuscate only renames Dart symbols. String literals and the object pool are untouched. As the pp.txt example above showed, every hardcoded string remains fully readable regardless of obfuscation.

5. Detect rooted devices and runtime hooks
If your app handles sensitive data, detect the environment it is running in and refuse to operate when that environment is hostile. You can detect known root management apps (Magisk, SuperSU, etc.) and instrumentation frameworks like Frida. Two Flutter packages worth knowing:

freerasp — a broader runtime self-protection package covering root detection, hook detection, debugger detection, emulator detection, and tamper detection.
flutter_jailbreak_detection — a simpler, more focused option for root/jailbreak checks.

6. For high-risk apps: full RASP
The most comprehensive protection is RASP (Runtime Application Self-Protection) — tools that continuously verify app integrity at runtime, detect tampering, and respond to attacks while the app is running. For finance, healthcare, and other regulated domains, RASP is increasingly an expectation, not an option.

Key takeaways

A release Flutter APK is not a black box. Static analysis with apktool alone can expose manifests, assets, and hardcoded values.
flutter_dotenv is not a secrets manager. Anything in the asset bundle is effectively public.
AOT-compiled libapp.so can be decompiled. Tools like B(l)utter expose every hardcoded string, class structure, and function address.
–obfuscate renames symbols but leaves string literals and the object pool readable.
The only durable protection for secrets is server-side. Use a backend proxy, scoped key restrictions, and deliver content-decryption keys only after verification.
Defend the runtime, not just the binary. Combine –obfuscate, root/hook detection (freerasp, flutter_jailbreak_detection), and — for high-risk apps — full RASP.

Frequently asked questions:

Can a Flutter app be reverse-engineered?
Yes. Both debug and release Flutter apps can be reverse-engineered. Debug builds use JIT compilation and produce a high-level Kernel AST from which near-original source can be recovered. Release builds use AOT compilation and produce libapp.so, which can be decompiled with tools like B(l)utter and reFlutter to recover function structure, class layouts, and every hardcoded string in the object pool.

Does Flutter build –obfuscate make a Flutter app secure?
No. The –obfuscate flag only renames Dart symbols (class and field names). String literals, API keys, and the entire object pool remain readable in the compiled binary. Obfuscation increases the effort required to read the code, but it does not encrypt or protect any embedded data.

Is it safe to use flutter_dotenv for production API keys?
No. The flutter_dotenv package itself warns that its values should be treated as public client-side configuration. Anything in the asset bundle ships unencrypted inside the APK and can be extracted with apktool in seconds. For production secrets, use a backend proxy or use the third-party provider’s key restrictions.

What is the difference between AOT and JIT compilation in Flutter?
JIT (Just-In-Time) compilation is used in Flutter debug builds. The Dart source becomes a high-level Kernel AST that is compiled to machine code on-device at runtime, enabling features like hot reload. AOT (Ahead-Of-Time) compilation is used in Flutter release builds. The Dart source is compiled in advance to native ARM machine code plus a heap snapshot, packaged as libapp.so. AOT is faster at runtime but produces a binary that is closer to native code and more compact.

How do I prevent reverse engineering of a Flutter app?
You cannot fully prevent reverse engineering of any client-side app — but you can make it expensive enough not to be worth the attacker’s time. The most effective combination: (1) keep secrets server-side and proxy sensitive requests, (2) encrypt bundled assets and deliver decryption keys only after server-side verification, (3) build releases with –obfuscate and –split-debug-info, (4) add root/jailbreak and hook detection with freerasp or flutter_jailbreak_detection, and (5) for high-risk domains, add a full RASP solution.

What is libapp.so in a Flutter Android build?
libapp.so is the native shared library produced by Flutter’s AOT compiler. It contains the machine code compiled from your Dart source plus a pre-built heap snapshot — a memory image of all the objects the app needs at startup, including string literals, constants, and type metadata. At launch, libflutter.so (the Flutter engine) loads libapp.so and maps the snapshot directly into the Dart heap.

Building Flutter apps that survive real-world attack
At NERDZ LAB, we have been shipping production Flutter apps across healthcare, fintech, and consumer markets since 2017. Security is not a feature you bolt on at the end — it is an architectural decision that starts on day one. On the Yakaboo project (Ukraine’s largest online bookstore, with 14,000+ e-books and audiobooks), we built a custom Flutter e-book reader from scratch with at-rest encryption, DRM, jailbreak/root detection, secure display, and offline DRM with a 30-day grace period. The reader runs on iOS and Android with no backend — every protection lives on the device.

If you are building a Flutter app that handles sensitive data — patient records, financial transactions, paid content, regulated information — and you want a partner who treats mobile security as a first-class engineering concern, we would be glad to talk.

Start with our Flutter and mobile development services, or book a call directly with our team.

How we use AI across our development workflow

NERDZ LAB — Tue, 02 Jun 2026 12:47:30 +0000

The tools we run, how we run them, and 14 practices our team applies every day.

AI coding tools are everywhere right now. Most development teams have one or two people experimenting — a tool here, a plugin there. The results are mixed, the patterns are inconsistent, and the gains are individual.

At NERDZ LAB, we took a different approach. AI assistance is not optional or ad-hoc — it is embedded into every stage of our development process, standardized across the entire team, and integrated directly into our toolchain. Every developer runs the same setup. Every project starts with the same foundation. This is the full picture: the tools we use, what each one does, and the 13 operational practices our team applies across web, mobile, and back-end development to make AI- assisted work actually work.

Our AI toolchain: what we actually use

Our workflow is built around four tools with distinct, non-overlapping roles.

Claude Code is the foundation. Every developer on the team — web, mobile, and back-end — uses it as the primary AI coding assistant, with a shared library of custom hooks and skills that standardize how AI is applied across every project. This covers the full development lifecycle: feature development, debugging, refactoring, code review, and deployment preparation. The assistance is not ad-hoc — it follows consistent, auditable patterns regardless of the platform being built.

Figma MCP closes the design-to-code gap. Our environment reads Figma component data directly via the Model Context Protocol and generates production-ready UI code — React and TypeScript for web, SwiftUI for iOS, Flutter widgets for mobile. Designers publish components in Figma; developers build from that single source of truth. Manual design-to-code translation is largely eliminated.

Claude Code Review provides an AI-assisted first-pass review on Pull Requests before a human reviewer sees it. It surfaces style violations, logic issues, and potential bugs at the code level. Senior developers spend their review time on architecture decisions and business logic — not mechanical consistency checks.

Ralph is our autonomous agent for high-complexity tasks. Large refactors and scaffolding get routed to Ralph based on scope and oversight requirements. It also executes structured tasks based on a PRD — not every task needs autonomous execution, but for the right jobs, it delivers significant acceleration.

What this workflow delivers
The most measurable impact is speed. AI cuts our UI implementation time by approximately 50% — across web front-ends, mobile apps, and back-end services alike. Broader tasks — integrations, refactoring, large-scale structural changes — see
meaningful gains too, varying by complexity.

But the more important result is consistency. When a project is well-configured, and the AI follows the team’s standards, it maintains that standard rather than eroding it. Code style is more uniform across the team, regardless of platform. Fewer issues reach human review. Senior engineers focus on what actually requires their judgment.

Debugging is faster across every stack — a failing database query, a state management bug, a UI rendering issue — AI enables instant hypothesis testing instead of lengthy reproduction cycles. PR preparation is largely automated. Code review is more meaningful because the mechanical work is already handled.

13 practices our team uses every day
The toolchain is only part of the equation. How you operate within that toolchain determines whether you see marginal gains or transformational ones. These 13 practices apply regardless of what you are building — web, mobile, or back-end. They are drawn directly from our team’s daily workflow across all three disciplines.

Use planning mode and break work into small tasks with checkpoints.

Claude Code’s planning mode lets you review the proposed approach before execution begins. Beyond that, we break every task into small steps with a fixed “known good” checkpoint between each one. AI quality degrades as context grows — larger context means more drift from the original goal. Small steps with rollback points keep the model focused and make recovery cheap when something goes wrong.

Use Claude Opus for planning, Claude Sonnet for implementation.

Opus reasons better on architecture, edge cases, and complex design decisions — we use it at the planning stage. Sonnet is faster and more cost-efficient, making it ideal for serial code generation during implementation. Matching the right model to the right task reduces cost without sacrificing quality at either stage.

Use AI for debugging, refactoring, and CI/CD — not just code generation.

The biggest value Claude Code delivers is not writing new code — it is understanding existing code. This holds across every platform: describe a failing database query, a broken state update, or a rendering issue, and get a ranked set of hypotheses to test in order. Refactoring via AI lets you remove technical debt safely, with the model tracking dependencies you might miss. Automated PR descriptions and first-pass code review in CI/CD reduce the manual load across the whole team, regardless of language.

Run parallel Claude Code sessions for independent tasks.

Claude Code sessions are fully isolated — one tab does not know another. When two tasks do not share files or state, we run them as parallel agents. There is no coordination overhead and no interference. The speedup is roughly linear with the number of parallel sessions.

Use Esc+Esc to revert when the model goes off course.

When Claude Code heads in the wrong direction, double-Esc reverts to the previous clean state. Correcting a derailed model costs significantly more than reverting early and restarting with a tighter prompt. Equally important: be deliberate about context. What you keep in context directly shapes the quality of the next response. Cut irrelevant history before it accumulates.

Run Claude init at the start of every project.

CLAUDE.md is Claude Code’s long-term memory for a project. We populate it with architectural decisions, naming conventions, team standards, and explicitly forbidden patterns. The specifics vary by platform — a Flutter project defines widget composition rules and state management patterns; a Laravel project encodes PSR-12 standards and DDD folder structure; a Swift project covers actor isolation and concurrency rules. The principle is the same across all of them: without CLAUDE.md, the model makes generic assumptions that are often wrong for your codebase.

Connect Claude Code to every tool via MCP integrations.

Model Context Protocol (MCP) transforms Claude Code from a coding assistant into an active participant in the full workflow. Figma MCP reads design components and generates production-ready UI code — React/TypeScript for web, SwiftUI for iOS, Flutter widgets for mobile. Playwright MCP enables AI-driven browser automation and testing. GitHub MCP creates pull requests without manual copy-paste. Each connected server eliminates an entire category of manual work, regardless of your stack.

Restrict .env and sensitive files in CLAUDE.md.

Claude Code can unintentionally include API keys, credentials, or secrets in generated code, log output, or inline explanations. A single explicit restriction in CLAUDE.md — blocking access to .env and credential files — is the simplest and most reliable safeguard. This applies equally to web, mobile, and back-end projects. We treat it as a non-negotiable configuration step on every single project.

Start a new context for every new task.

Residual context from a previous task is noise for the next one. Claude Code will try to stay “consistent” with previous decisions — even when those decisions are completely irrelevant to the new work. A clean session start means clean, unbiased output. We never carry over context from one task to the next.

Monitor the Claude Code status bar to manage context window health.

The context window is not infinite. As it fills up, response quality degrades, and older details get quietly forgotten. The Claude Code status bar shows current context usage in real time. We compress context or start a fresh session before the window fills — not after we notice quality dropping.

Use extended thinking for architecture and complex decisions.

A standard Claude Code response is a single inference pass. Extended thinking activates an internal reasoning chain before the answer is generated. On architectural decisions, complex algorithm design, or multi-system refactors, the quality difference is noticeable — the model catches edge cases and contradictions it would otherwise miss.

Build custom skills for any repeated workflow.

Explaining “how we write PR descriptions” or “how we structure unit tests” in every session is wasted context and wasted time. We encode those patterns once as custom skills in Claude Code. From that point forward, the expertise applies automatically — no re-prompting, no inconsistency across team members. Our Laravel team has encoded Spatie PHP guidelines and Domain-Driven Design patterns as skills. The mobile team has SwiftUI composition rules and Flutter state management conventions. Open-source skill libraries like laravel/agent-skills and SwiftUI-Agent-Skill on GitHub mean teams do not have to build everything from scratch.

Monitor and control long agent tasks from your phone.

An autonomous agent running complex tasks can take 20 to 40 minutes. Rather than staying at the desktop waiting, Claude Code supports remote monitoring and control — you can review progress, approve a pending step, or stop the agent entirely from your phone. Long agent tasks become background processes. You stay unblocked.

What this means if you work with us
This is not a pilot program or an experiment. It is how every project at NERDZ LAB is built today — across our 80+ team, 250+ delivered projects, and every client engagement we take on. For you, that means faster delivery without reduced quality. More predictable timelines, because AI handles the repeatable parts that cause slowdowns. Your budget goes further — our team delivers more per sprint by eliminating friction, not by working more hours.

We have shipped products used by millions — from an app with 2M+ downloads and Apple’s App of the Day recognition, to platforms serving 750,000+ patients. Our clients have collectively raised $535M in funding. This workflow is part of how we consistently get there.

If you are building a product and want to see what a fully AI-integrated development team looks like for your project, let’s talk.

Book a free consultation

Explore our case studies