DEV Community: Robin Alex Panicker

AxKeyStore: A Zero-Trust CLI for Managing Secrets Using GitHub as Your Backend

Robin Alex Panicker — Sun, 29 Mar 2026 11:18:28 +0000

Most developers today juggle secrets across multiple environments—API keys, database credentials, tokens, signing keys. The typical solutions fall into three buckets:

.env files (simple, but unsafe and unscalable)
Cloud secret managers (secure, but expensive and vendor-locked)
Password managers (not developer-native)

AxKeyStore introduces a different approach:

Use your own GitHub repository as an encrypted, versioned, zero-trust secret store—fully controlled by you.

This article breaks down how AxKeyStore works, why its architecture matters, and how you can integrate it into your workflow.

AxKeyStore is MIT Licensed Open Source project - https://github.com/basilgregory/axkeystore

The Core Idea

AxKeyStore is a CLI-first secret manager that:

Stores secrets in your own private GitHub repo
Uses client-side encryption only
Treats GitHub as untrusted storage
Ensures no plaintext secrets ever leave your machine

This flips the traditional model:

Traditional Secret Manager	AxKeyStore
Trust the provider	Trust only your machine
Secrets decrypted in cloud	Secrets decrypted locally
Vendor-controlled infra	Your GitHub repo
Centralized trust	Zero-trust

Architecture Overview

AxKeyStore is built on a multi-layer encryption model designed for strict isolation and zero trust.

1. Key Hierarchy

There are two core keys:

Local Master Key (LMK)

Generated per profile
Stored locally
Encrypts:
- GitHub token
- Repository configuration

Remote Master Key (RMK)

Stored in GitHub (encrypted)
Used to encrypt actual secrets

2. Encryption Layers

Secret → encrypted with RMK
RMK → encrypted with Master Password
Local config → encrypted with LMK
LMK → encrypted with Master Password

This creates a 3-layer protection model:

Secrets are never stored in plaintext
GitHub only sees encrypted blobs
Even local config is encrypted

3. Cryptography Choices

AxKeyStore uses modern primitives:

XChaCha20-Poly1305 → authenticated encryption
Argon2id → password-based key derivation
Client-side encryption only

Implication:

Even if GitHub is compromised, your secrets remain secure.

Why GitHub as a Backend?

This is the most unconventional design decision—and also the most powerful.

Benefits

1. Version Control for Secrets

Every update becomes a commit.

axkeystore history "api-key"

You get:

Full audit trail
Rollbacks via commit SHA
Time-based debugging

2. Free, Reliable Infrastructure

No infra to maintain
No billing surprises
Global availability

3. Ownership & Portability

You control the repo
No vendor lock-in
Works across machines instantly

Developer Experience

AxKeyStore is designed for daily CLI usage, not dashboards.

Setup

axkeystore login
axkeystore init --repo my-secret-store

Store a Secret

axkeystore store --key "stripe-api-key" --value "sk_live_..."

Or auto-generate:

axkeystore store --key "jwt-secret"

Retrieve a Secret

axkeystore get "stripe-api-key"

Organize by Environment

axkeystore store \
  --key "db-password" \
  --category "prod/database"

This creates structured storage:

prod/database/db-password

List Everything

axkeystore list

Output:

[prod/database]
  db-password = ****

[api]
  stripe-key = ****

Profiles: Multi-Environment Isolation

AxKeyStore supports multiple profiles, each with:

Separate GitHub repo
Separate master password
Separate keyspace

Example:

axkeystore profile create work
axkeystore profile switch work

Use cases:

Personal vs Work
Dev vs Prod
Multi-tenant SaaS ops

Security Model Deep Dive

Let’s break down the threat model.

What if GitHub is compromised?

Attacker sees:

Encrypted blobs
Encrypted RMK

They cannot decrypt:

RMK (needs master password)
Secrets (needs RMK)

What if local machine is compromised?

Attacker sees:

Encrypted LMK
Encrypted token

Still needs:

Master password

What if both are compromised?

Only then:

System becomes vulnerable

This is consistent with zero-trust design principles.

How It Compares

vs `.env` Files

Feature	`.env`	AxKeyStore
Encryption	❌	✅
Versioning	❌	✅
Sharing	Manual	GitHub-native
Security	Weak	Strong

vs Cloud Secret Managers

Feature	Cloud (AWS/GCP)	AxKeyStore
Cost	$$$	Free
Setup	Complex	Simple
Lock-in	High	None
Control	Limited	Full

vs Vault (HashiCorp)

Feature	Vault	AxKeyStore
Infra required	Yes	No
Ops overhead	High	Zero
Dev UX	Moderate	CLI-native

Where AxKeyStore Fits Best

AxKeyStore is ideal for:

1. Indie Hackers / Startups

No infra overhead
Free secret storage
Works instantly

2. CLI-first Engineers

No dashboards
Scriptable
Fast workflows

3. Multi-Repo Developers

Secrets tied to GitHub repos
Natural workflow integration

Where It May Not Fit

Enterprises needing:
- RBAC policies
- Secret rotation automation
- Compliance (SOC2, etc.)
Real-time secret injection into runtime (no agent model yet)

Advanced Use Cases

1. CI/CD Integration

You can pull secrets during pipeline execution:

SECRET=$(axkeystore get "api-key")

2. Version Debugging

Roll back to a previous secret:

axkeystore get "api-key" --version <SHA>

3. Secret Generation

Let AxKeyStore generate secure values:

axkeystore store --key "jwt-secret"

Internal Design Insights (For Builders)

AxKeyStore is implemented in:

Rust
Async via tokio
CLI via clap

Key design decisions:

1. GitHub as API Layer

Uses GitHub Contents API
Stores secrets as files
Leverages commit history

2. Profile Isolation via Filesystem

Each profile has its own config:

~/.config/com.ax.axkeystore/

3. No Plaintext Persistence

Everything encrypted at rest
No caching of decrypted values

Strategic Insight

AxKeyStore represents a broader shift:

Decoupling infrastructure from trust

Instead of:

Trusting AWS / Vault / providers

You:

Trust cryptography
Own storage
Control access

This pattern will likely expand into:

Logs
Analytics
Observability (similar to what tools like Appxiom are doing)

Final Thoughts

AxKeyStore is not trying to replace enterprise secret managers.

It’s targeting a different segment:

Developers who want control, simplicity, and strong security without infrastructure overhead

If your current workflow involves:

.env files
Copy-pasting secrets
Manual sharing

Then AxKeyStore is a meaningful upgrade.

Get Started

curl -sSL https://raw.githubusercontent.com/basilgregory/axkeystore/main/install.sh | bash

Then:

axkeystore login
axkeystore init --repo my-secret-store

If you’re building developer tools or care about security architecture, AxKeyStore is worth studying—not just using.

It’s a clean example of:

Zero trust
Client-side encryption
Leveraging existing infra (GitHub) in unconventional ways

Top 5 ANR Detection Tools for Flutter Apps in 2026

Robin Alex Panicker — Sun, 22 Mar 2026 07:11:54 +0000

Application Not Responding (ANR) issues are one of the most frustrating performance problems in Android mobile apps. Unlike crashes, ANRs silently degrade user experience-leading to app abandonment, poor ratings, and revenue loss.

For Flutter apps, detecting ANRs is even more complex because issues can originate from:

Dart (UI thread / isolates)
Native Android code (main thread blocking)
Platform channels (Flutter ↔ native bridge)

In 2026, modern monitoring tools go beyond simple logging-they provide real-time detection, root cause analysis, and user journey context.

Here are the top 5 ANR detection tools for Flutter apps in 2026.

1. Firebase Crashlytics

Website: https://firebase.google.com/products/crashlytics

Overview

Firebase Crashlytics remains one of the most widely used tools for mobile error monitoring. It provides basic ANR detection on Android along with crash reporting.

While primarily designed for crashes, Crashlytics can surface ANRs through system-level signals and integrates with Firebase Performance Monitoring.

Key Features

Real-time crash and ANR alerts
Lightweight SDK with minimal overhead
Tight integration with Firebase ecosystem
Basic stack trace visibility

Pros

Free and easy to set up
Widely adopted and well-documented
Works seamlessly with Flutter
Good starting point for small teams

Cons

Limited ANR insights (no deep root cause analysis)
No session-level context or user journey mapping
Difficult to debug complex UI freezes
Not ideal for large-scale performance monitoring

2. Sentry

Website: https://sentry.io

Overview

Sentry is a developer-first observability platform that provides detailed error tracking, performance monitoring, and partial ANR visibility.

It is particularly strong in debugging context, offering deep insights into what happened before an issue occurred.

Key Features

Real-time error and performance monitoring
Distributed tracing
Release tracking and regression detection
Detailed stack traces and breadcrumbs

Pros

Extremely rich debugging context
Strong Flutter SDK support
Supports backend + frontend in one tool
Flexible alerting and workflows

Cons

ANR detection is indirect (via performance spans, not native ANR signals)
Can become expensive at scale
Requires tuning to avoid noisy alerts

3. Appxiom

Website: https://www.appxiom.com

Overview

Appxiom is a next-generation mobile observability platform built specifically for modern apps, including Flutter.

Unlike traditional tools, Appxiom doesn’t just detect ANRs—it connects them to real user journeys and business impact.

Most importantly:

Appxiom detects ANRs across both Dart and native layers, giving full visibility into Flutter apps.

Key Features

Real-time ANR detection (Dart + native Android)
User journey-based issue mapping
Business impact analysis (conversion, drop-offs)
Detection of 30+ issue types including freezes, memory, and API delays
Alerts with Jira/Slack integration

Why It Stands Out

Traditional tools answer:

“Did an ANR happen?”

Appxiom answers:

“Which user flow broke, how many users were affected, and what revenue impact it caused?”

This shift is critical for modern product teams.

Pros

Detects ANRs in both Dart and native code (unique advantage)
Prioritizes issues based on real user impact
Provides full journey context, not just logs
Designed specifically for mobile apps (including Flutter)
Helps reduce MTTR significantly

Cons

Newer compared to legacy tools
Requires mindset shift (from logs → impact-driven debugging)
Not a generic backend observability tool

4. Instabug

Website: https://www.instabug.com

Overview

Instabug combines crash reporting, ANR detection, and user feedback tools into a single platform.

It is particularly strong in detecting app hangs and UI freezes, which are often precursors to ANRs.

Key Features

ANR detection on Android
App hang detection (iOS & Flutter)
In-app bug reporting
Session replay and user feedback

Pros

Strong focus on user experience issues
Captures freezes even without crashes
Combines performance + feedback in one platform
Great for QA and product teams

Cons

Premium pricing for advanced features
Limited direct correlation to business metrics
Session replay not always available in lower tiers

5. Embrace

Website: https://embrace.io

Overview

Embrace is a mobile-first observability platform designed to provide full visibility into app performance, including ANRs.

It focuses heavily on session-based monitoring, capturing everything that happens during a user session.

Key Features

Full session timelines (including ANRs and performance issues)
Network and device state tracking
OpenTelemetry support
Real-time alerts

Pros

Captures 100% of user sessions
Strong ANR and performance visibility
Excellent for large-scale mobile apps
Provides full context (network, device, user actions)

Cons

Paid tool (can be expensive)
Requires setup and configuration effort
Might be overkill for small teams

Final Thoughts

ANR detection in Flutter apps is no longer just about catching freezes—it’s about understanding impact, context, and root cause across multiple layers.

Quick Comparison

Tool	ANR Detection Depth	Flutter Support	Unique Strength
Firebase Crashlytics	Basic	Yes	Free + easy setup
Sentry	Medium	Yes	Deep debugging context
Appxiom	Advanced	Yes	Dart + ANR + business impact
Instabug	Medium	Yes	UX + feedback + freeze detection
Embrace	Advanced	Yes	Full session observability

Conclusion

If you're building Flutter apps in 2026:

Start with Crashlytics for basic monitoring
Use Sentry or Embrace for deeper debugging
Choose Appxiom if you want complete ANR visibility across Dart + native + business impact

The future of debugging isn’t just “what broke” - it’s “what mattered, for whom, and why.”

Top 5 Bug & Performance Issue Detection Tools for Flutter Apps in 2026

Robin Alex Panicker — Wed, 18 Mar 2026 11:40:16 +0000

Flutter has evolved into a powerful framework for building high-performance cross-platform apps. But as apps scale, detecting bugs and performance issues in real-world usage becomes critical.

In 2026, the focus is no longer just on crash reporting. Teams now need:

Real user monitoring
Performance insights
Business impact visibility

In this article, we explore the top 5 tools Flutter teams should use in 2026.

1. Firebase Crashlytics + Performance Monitoring

Website: https://firebase.google.com

Overview

Firebase provides an easy-to-integrate solution for crash reporting and performance monitoring in Flutter apps.

It automatically tracks app performance metrics and gives insights into crashes across devices.

Key Capabilities

Real-time crash reporting
App startup time tracking
Network performance monitoring
Custom performance traces
Integration with Firebase ecosystem

Pros

Very easy to integrate
Generous free tier
Strong ecosystem (Analytics, Remote Config, etc.)
Ideal for startups

Cons

Limited deep debugging capabilities
No business impact prioritization
Can become noisy at scale

Best For

Small teams and startups looking for quick setup and basic monitoring

2. Sentry

Website: https://sentry.io

Overview

Sentry is a widely used platform for error tracking and performance monitoring across mobile and backend systems.

It provides deep debugging insights with detailed stack traces and environment context.

Key Capabilities

Detailed error tracking
Performance tracing
Release tracking
Cross-platform support

Pros

Very detailed debugging information
Supports mobile + backend
Strong developer workflows

Cons

Can get expensive
Requires tuning to reduce noise
Slight learning curve

Best For

Teams that need deep debugging and detailed error insights

3. Appxiom

Website: https://www.appxiom.com

Overview

Appxiom is a modern observability platform that detects bugs and performance issues and maps them to user journeys.

For example, a delay in the sign-up flow is treated as more critical than a crash in a rarely used screen because it directly impacts user acquisition and CAC.

Unlike traditional tools, Appxiom helps teams understand which issues actually impact business outcomes.

Key Capabilities

Detects crashes, ANRs, memory issues, HTTP failures, and UI freezes
Maps issues to user journeys (signup, checkout, etc.)
Prioritizes bugs based on real user impact
Detects feature failures and custom issues
Supports Flutter, Android, and iOS

Pros

Business-impact-driven debugging
Detects both technical and functional issues
Strong focus on real user experience
Helps prioritize critical issues faster

Cons

Newer tool compared to others
Smaller ecosystem
Requires mindset shift from traditional debugging

Best For

Teams that want to focus on user experience and business impact instead of just crashes

4. Datadog (Mobile APM)

Website: https://www.datadoghq.com

Overview

Datadog is an enterprise-grade observability platform offering full-stack monitoring, including Flutter apps.

It connects mobile performance with backend systems for a complete picture.

Key Capabilities

Real User Monitoring (RUM)
Distributed tracing
Log monitoring
Backend correlation

Pros

Full-stack observability
Excellent dashboards and alerts
Scales well for large systems

Cons

Expensive
Complex setup
Overkill for small apps

Best For

Large teams building distributed systems with Flutter frontends

5. AppDynamics (Cisco)

Website: https://www.appdynamics.com

Overview

AppDynamics provides enterprise-level application performance monitoring (APM) with strong focus on business transactions.

It helps track how user actions flow through backend systems.

Key Capabilities

Real User Monitoring
Business transaction tracking
Backend performance correlation

Pros

Strong enterprise capabilities
Deep transaction visibility
Good backend integration

Cons

Complex setup
High cost
Limited Flutter-focused community

Best For

Enterprises needing end-to-end visibility across systems

Final Comparison

Tool	Strength	Best Use Case
Firebase	Easy + free + ecosystem	Startups
Sentry	Deep debugging	Dev-focused teams
Appxiom	Business-impact debugging	Product-focused teams
Datadog	Full-stack observability	Large-scale systems
AppDynamics	Enterprise APM	Enterprise apps

Key Takeaways for 2026

Crash reporting alone is not enough
Real-user monitoring is essential
Business impact is the new priority

Modern tools like Appxiom are shifting the focus from:

“What broke?” → “What impacted users and revenue?”

Conclusion

Choosing the right tool depends on your stage:

Startups: Firebase
Growing teams: Sentry
Product-focused teams: Appxiom
Enterprises: Datadog or AppDynamics

The best teams in 2026 don’t just fix bugs — they fix what matters most to users.

Replacing Nested Maps with Tuple Keys in Java and Kotlin

Robin Alex Panicker — Fri, 27 Feb 2026 05:07:07 +0000

We at Appxiom built a simple but useful library for Java and Kotlin.

AxTuple (ax-tuple-java) is a MIT Licensed lightweight library available as Maven library and Gradle plugin.

Let's try AxTuple in a real-world scenario where we have a deeply nested HashMap structure. The goal is simple: reduce complexity without introducing unnecessary DTOs.

AxTuple is extremely practical for flattening multi-layer maps into clean, readable composite keys - while remaining immutable and safe to use in hash-based collections.

In this post, I’ll walk through:

The problem with nested maps
The clean alternative using Tuple
When to use NamedTuple instead
Java and Kotlin examples
Practical observations after testing

The Problem: Nested HashMap

Let’s say we are tracking feature usage in an application.

We want to count how many times a feature is used based on:

Environment (prod, staging)
Region (us-east, eu-west)
Feature name (dark_mode, search_v2)

The naive structure looks like this:

Map<String, Map<String, Map<String, Integer>>> usage = new HashMap<>();

Updating the Count (Java)

usage
    .computeIfAbsent("prod", e -> new HashMap<>())
    .computeIfAbsent("us-east", r -> new HashMap<>())
    .merge("dark_mode", 1, Integer::sum);

This works — but:

Hard to read
Hard to debug
Null-safety complexity
Deep nesting
Ugly generics
Painful refactoring

After testing this approach in a medium-sized codebase, it quickly became clear that the structure itself was the problem.

The Clean Solution: Flatten with Tuple Keys

Instead of nesting maps, we flatten everything.

One key. One map.

Map<Tuple, Integer> usage = new HashMap<>();

Now the key contains all three dimensions:

Tuple key = Tuple.of("prod", "us-east", "dark_mode");

Java Example

import com.appxiom.ax.tuple.Tuple;
import java.util.HashMap;
import java.util.Map;

Map<Tuple, Integer> usage = new HashMap<>();

Tuple key = Tuple.of("prod", "us-east", "dark_mode");

// Increment count
usage.merge(key, 1, Integer::sum);

// Increment again
usage.merge(key, 1, Integer::sum);

System.out.println(usage.get(Tuple.of("prod", "us-east", "dark_mode")));
// Output: 2

Why This Works

AxTuple implements:

Proper equals()
Proper hashCode()
Immutability

So even if you create a new Tuple instance with the same values, it still resolves correctly in the HashMap.

I verified this by:

Creating keys in one method
Looking them up in another
Reconstructing keys dynamically

No collisions. No surprises.

Kotlin Version

import com.appxiom.ax.tuple.Tuple

val usage = mutableMapOf<Tuple, Int>()

val key = Tuple.of("prod", "us-east", "dark_mode")

usage.merge(key, 1, Int::plus)
usage.merge(key, 1, Int::plus)

println(usage[Tuple.of("prod", "us-east", "dark_mode")])
// Output: 2

Much cleaner than nested maps.

Before vs After

Nested Map Structure

Map<String, Map<String, Map<String, Integer>>> usage;

Flat Structure

Map<Tuple, Integer> usage;

The second one is:

Easier to understand
Easier to pass around
Easier to serialize
Easier to test

And most importantly: less cognitive load.

NamedTuple Is Even Better

Tuple works great when order is clear.

But sometimes readability matters more than position.

Instead of:

Tuple.of("prod", "us-east", "dark_mode");

You may prefer:

NamedTuple.of(Map.of(
    "env", "prod",
    "region", "us-east",
    "feature", "dark_mode"
));

Java Example with NamedTuple

import com.appxiom.ax.tuple.NamedTuple;
import java.util.HashMap;
import java.util.Map;

Map<NamedTuple, Integer> usage = new HashMap<>();

NamedTuple key = NamedTuple.of(Map.of(
    "env", "prod",
    "region", "us-east",
    "feature", "dark_mode"
));

usage.merge(key, 1, Integer::sum);

NamedTuple lookup = NamedTuple.of(Map.of(
    "env", "prod",
    "region", "us-east",
    "feature", "dark_mode"
));

System.out.println(usage.get(lookup));
// Output: 1

Why I Liked NamedTuple

Debug logs are clearer
Keys are self-documenting
Refactoring is safer
Order mistakes are impossible

The only tradeoff is slightly more verbosity.

Observations

After testing with:

~100K inserts
Repeated lookups
Reconstructed key objects

Flat HashMaps with Tuple keys performed much faster when looping through.

What improved dramatically was:

Code readability
Maintainability
Refactoring safety
Test simplicity

When Should You Use AxTuple?

Use it when:

You have multi-dimensional map keys
You are building analytics counters
You want to avoid nested map hell
You don’t want to create a one-off composite key class
You want immutable composite keys

Avoid it when:

You need domain-rich behavior (then create a proper class)
Your key semantics are complex and deserve explicit modeling

Thoughts

After testing AxTuple in a real nested-map scenario, I can confidently say:

Flattening multi-layer HashMaps with Tuple keys significantly simplifies design.

Instead of:

Map<A, Map<B, Map<C, V>>>

You get:

Map<Tuple, V>

Cleaner.
More maintainable.
Less boilerplate.

And because AxTuple is immutable and hash-safe, it behaves exactly how a composite key should.

If you are dealing with multi-dimensional counters, caches, or analytics maps - this pattern is worth adopting.

Sometimes the best refactor isn’t adding a new abstraction.

It’s removing unnecessary structure.

For more on AxTuple - visit https://github.com/basilgregory/ax-tuple-java

Debug Like a Pro with 'git bisect'

Robin Alex Panicker — Sun, 09 Mar 2025 09:56:22 +0000

Most programmers spent hours checking git commits to identify which commit introduced the bug. It’s frustrating. But instead of manually checking commit after commit, Git has a built-in tool that saves your time using Binary Search — git bisect!

Let me walk you through it. It’s easier than you think.

Step 1: Start Bisecting

First, tell Git you want to start looking for the bad commit:
git bisect start

That’s it! Now Git knows you’re about to go on a debugging hunt.

Step 2: Mark a "Good" and "Bad" Commit

Now, we need to give Git some context. Find a past commit where everything worked fine and mark it as good:
git bisect good <commit-hash>

Then, mark the commit where the bug appeared as bad:
git bisect bad <commit-hash>

Don’t know the exact good commit? No worries—just pick an older one where you think things were stable.

Step 3: Let Git Do the Heavy Lifting

Now comes the magic! Git will check out a commit in the middle of the range. You test it and tell Git whether the bug is there or not.

If the bug isn’t there, run:
git bisect good

If the bug exists, run:
git bisect bad

Git keeps narrowing it down until it finds the exact commit that introduced the issue.

Step 4: End Bisect & Fix the Bug

Once Git pinpoints the problematic commit, reset everything back to normal:
git bisect reset

Then, take a look at the commit, figure out what went wrong, and fix the bug at its source!

BTW if you have a test script that can detect the bug automatically, you don’t even have to manually test each commit! Just run:
git bisect run ./test-script.sh

Git will keep running the script until it finds the bad commit — completely hands-free debugging!

If you haven’t tried git bisect yet, give it a shot! It might just become your new favorite debugging tool.

Don't forget to share this. Might help someone in your network.

We migrated our backend tech stack to Rust, Java & Angular. Here is why.

Robin Alex Panicker — Thu, 17 Oct 2024 03:48:04 +0000

We are through with the server tech stack migration at Finotes.

For those who don't know what Finotes is (Oh! we have much to do in marketing front), it is a lightweight SDK that when integrated to any #iOS or #Android app, captures bugs and performance issues like memory leak, network call issues, frame rate issues, ANR / App Hang, crashes, screen loading delays and more.

Our backend attracts heavy load (oh yes, the number of bugs that exist in mobile apps is much higher than many think, and we capture and report all of them) and the operations are memory intensive. Our CPU usage is at manageable levels.

Our old stack was #Java + #NodeJS + #AngularJS (old one), where Java was used in core modules, NodeJS for dashboard backend and AngularJS for frontend. And now we use #Rust for core heavy load operations, Java (#SpringBoot) for dashboard backend, and #Angular for frontend. We also moved our RDBMS to a distributed table architecture for efficient insertions.

The reason to choose Rust was to ensure better memory efficiency compared to GC languages. The single owner memory model is a bit of a challenge to code, but the efforts pay off when it comes to memory efficiency. Will write a separate detailed post on how our new Rust based core engine compares with the previous Java based one in memory usage.

Moving from NodeJS to Java Spring Boot was a no-brainer as we wanted a compiled language to deliver licensed enterprise solutions without exposing the code.

Picking Angular for frontend was the most internally debated decision. Old AngularJS was outdated, and we wanted to move to a better and more modern framework. React (more of a library than a framework) vs Angular debates stretched many days. Finally the argument of better maintainability won, and we decided to go with Angular.

If you are a product startup at early stage, and is looking at different tech stack options, or if you are thinking of migrating to a new one, happy to share our learnings and how we reduced the server costs significantly with the new stack. DM me on LinkedIn.

Shared here is a screenshot of our dashboard. BTW this is not the final one, as this is couple of sprints old. In the latest, there are some new capabilities that we believe will be of much value to not just the developers, but also to the Software Engineering Leadership team. If you are part of the engineering leadership team in a mobile first company, happy to show a demo of the new capabilities. DM me on LinkedIn if you are interested.

What's new in Android 12

Robin Alex Panicker — Sun, 18 Jul 2021 15:08:52 +0000

Android 12 Developer preview is out since February. There are couple of interesting features and capabilities added to the release that developers can leverage. Regarding the new Material You UI, it's too early to take a call, but the AppSearch API is worth taking a look. The NoSQL LocalStorage and PlatformStorage will enable apps that can do high data processing.

Here is a high level analysis by @donpeter06 about the new features in Android 12.
https://www.blog.finotes.com/post/what-is-new-for-developers-in-android-12

Finotes 4.0.0 for Android, iOS & watchOS released

Robin Alex Panicker — Fri, 16 Apr 2021 09:45:59 +0000

Announcing the release of Finotes 4.0.0

Finotes SDK 4.0.0 for Android comes with improved screen load delay and ANR tracking. https://www.blog.finotes.com/post/finotes-sdk-version-4-0-0-for-android-released

Finotes Framework 4.0.0 for iOS comes with added customization capabilities while tracking screen load delays. https://www.blog.finotes.com/post/finotes-ios-framework-version-4-0-0-released

Finotes Framework 4.0.0 for watchOS comes with Zero-code HTTP tracking and life cycle event tracking. https://www.blog.finotes.com/post/finotes-watchos-framework-version-4-0-0-released-it-is-a-step-closer-to-no-code-integration

Do try it out. Visit https://finotes.com for more details.

Detect and Fix ANR in Android

Robin Alex Panicker — Thu, 08 Apr 2021 04:16:07 +0000

The recently released Finotes SDK 3.3.0 for Android has some significant improvements in ANR detection. The SDK now provides near perfect root cause detection of ANR issues in Android apps. The feature is enabled automatically with out any need for developer to write extra lines of code.

The new version is already getting appreciation from customers. Here is a screenshot of a mail from an Android developer at one of top global mobile apps. It clearly indicates his excitement on how Finotes was able to help him detect the root cause.

Visit https://www.blog.finotes.com/post/identifying-root-cause-of-anr-in-android-apps to know more about the improved ANR detection capability of Finotes.

Detecting HTTP issues and tracking lifecycle events in iOS apps using Finotes need no code change now

Robin Alex Panicker — Thu, 18 Mar 2021 06:10:11 +0000

Yes, that's the change in Finotes Framework 3.3.0. It's near zero effort to detect http call issues and also to track lifecycle events in iOS apps.

Why are we making these expensive mistakes?

Robin Alex Panicker — Fri, 19 Feb 2021 05:59:41 +0000

Source code getting leaked because no one bothered to remove the default credentials in git repo, bank losing millions because of a bad UI, tier 1 companies loosing almost a Trillion dollars due to digital transformation going wrong.

There is so much for software professionals to introspect about.

https://www.blog.finotes.com/post/how-not-to-be-a-stupid-software-engineer?fbclid=IwAR37YZMbwAyBJnR83MD1WqbfxC2ZBsm-wwfPZj1rYR1DwgqbGNvMhgjDY4A

Common bugs in mobile apps

Robin Alex Panicker — Mon, 01 Feb 2021 03:25:08 +0000

Finotes has released the report for Year 2020 on the common types of bugs reported from iOS and Android apps.

Take a look - https://www.blog.finotes.com/post/state-of-bugs-in-mobile-apps-finotes-report-for-year-2020

DEV Community: Robin Alex Panicker

AxKeyStore: A Zero-Trust CLI for Managing Secrets Using GitHub as Your Backend

The Core Idea

Architecture Overview

1. Key Hierarchy

Local Master Key (LMK)

Remote Master Key (RMK)

2. Encryption Layers

3. Cryptography Choices

Why GitHub as a Backend?

Benefits

1. Version Control for Secrets

2. Free, Reliable Infrastructure

3. Ownership & Portability

Developer Experience

Setup

Store a Secret

Retrieve a Secret

Organize by Environment

List Everything

Profiles: Multi-Environment Isolation

Security Model Deep Dive

What if GitHub is compromised?

What if local machine is compromised?

What if both are compromised?

How It Compares

vs .env Files

vs Cloud Secret Managers

vs Vault (HashiCorp)

Where AxKeyStore Fits Best

1. Indie Hackers / Startups

2. CLI-first Engineers

3. Multi-Repo Developers

Where It May Not Fit

Advanced Use Cases

1. CI/CD Integration

2. Version Debugging

3. Secret Generation

Internal Design Insights (For Builders)

1. GitHub as API Layer

2. Profile Isolation via Filesystem

3. No Plaintext Persistence

Strategic Insight

Final Thoughts

Get Started

Top 5 ANR Detection Tools for Flutter Apps in 2026

1. Firebase Crashlytics

Overview

Key Features

Pros

Cons

2. Sentry

Overview

Key Features

Pros

Cons

3. Appxiom

Overview

Key Features

Why It Stands Out

Pros

Cons

4. Instabug

Overview

Key Features

Pros

Cons

5. Embrace

Overview

Key Features

Pros

Cons

Final Thoughts

Quick Comparison

Conclusion

Top 5 Bug & Performance Issue Detection Tools for Flutter Apps in 2026

1. Firebase Crashlytics + Performance Monitoring

Overview

Key Capabilities

Pros

vs `.env` Files