While scrolling through Product Hunt, I came across something interesting called Dune:

“Dune is a Context-aware Keypad for Mac that sits next to your keyboard and changes what its three keys do in real time based on the app running in the foreground.” Source.

In essence, it’s a minimalist Macro Pad with just three keys designed to boost productivity. Despite its simplicity, Dune climbed to #1 Product of the Week on Product Hunt and sold out its very first pre‑order batch.

Clearly, people are drawn to this kind of device. The demand for macro pads is real.

Take the Stream Deck as another example. The best‑selling model on Amazon has moved over 9.9K units, with more than 1K purchases in the past month alone. For a gadget that only sells buttons — which priced on par with a smartphone — that’s impressive.

Macro Technology

These are amazing things. Yet, from a technical perspective, the concept isn’t groundbreaking; it’s essentially a shortcut system, something that has been around since the 1980s. But what makes Dune stand out isn’t the hardware, it’s the software.

Unlike traditional macro pads that rely on manual configuration and static profiles, Dune is context‑aware: its three keys automatically adapt to whichever app is active in the foreground. Instead of the user having to pre‑program every scenario, the device anticipates context and updates itself in real time.

This approach elevates the macro pad from a passive tool into something closer to an intelligent workflow assistant. In a way, Dune is redefining what a “macro pad” can be: not just extra buttons, but a dynamic extension of your digital environment.

Dune without Deck

I’ve already built my own macro pad before. But, can we push it further into dynamic key functions? The goal was simple:

1. Desktop Overlay: Minimalist UI on macOS that suggests shortcuts.
2. Mobile Remote: App on my phone that mirrors those shortcuts as touchable buttons, replacing the need for Dune’s physical hardware.
3. AI Agent: A lightweight agent that analyzes the active window and intelligently suggests the most relevant actions in real time.

The Stacks

I decide to spin up a new repository and build DONE — O’s for Open Source and Ollama Powered. The tech stack:

1. Python for the desktop orchestrator:
   Python gives me direct access to macOS through AppleScript, while PyQt6 powers a sleek “glassmorphism” overlay that feels native to the OS.
2. Flutter for the mobile remote:
   A grid of action buttons turns my phone into a dynamic extension of whatever app is active on my Mac, making shortcuts portable.
3. Ollama for AI Agent:
   Fully local and free. Users can swap between models of their choice.

The Challenges

Building an app like this came with unique challenges:

1. The “Boomerang Focus”
When you tap a button on your phone, the Mac needs to execute that shortcut. The problem: if the overlay has focus, the keystroke lands there instead of the target app. The workaround:

1. Tap on phone → signal sent to Mac.
2. Mac identifies the target app (e.g., Chrome).
3. Mac momentarily switches focus to Chrome.
4. Fires the keystroke (e.g., Cmd+T).
5. Snaps focus back to your previous state.

It’s so fast you don’t even see the flicker.

2. URL Normalization
LLMs can be expensive in compute, and I didn’t want the agent to regenerate shortcuts every time I switched YouTube videos. By stripping query parameters, the system recognizes that youtube.com/watch?v=123 and youtube.com/watch?v=456 are the same context. This enables aggressive caching and instant UI updates without wasted cycles.

3. The “Permission Fortress”
Building DONE taught me that macOS is a fortress when it comes to permission. Handling Accessibility access — or at least guiding the user through them — was a challenge itself.

But the result? When I open Youtube, my phone shows play/pause and skip. When I open IDE, it shows “Run Tests” and “Format Document.” The workspace feels alive.

GitHub - irfnyas/done: DONE is a minimalist, context-aware macOS productivity overlay that monitors your active application and uses local AI (via Ollama) to suggest relevant shortcuts and actions.

If you’re interested in the code, check out the repository here. Desktop and mobile app also available here, currently for MacOS and Android.

The Job isn’t Done

This project showed me that even small innovations (like context‑aware shortcuts) can spark bigger ideas about the next wave of human and computer interaction. I believe the future of productivity isn’t about “more apps”, but a thinner layer between our thoughts and our tools.

DONE is just the beginning, and the job isn’t done. Thank you for reading, happy coding.

It all started with a simple curiosity:
Can I simulate keyboard input on my PC using my phone?

So, I did what any modern dev does: I asked the AI.
The reply was instant: “It is absolutely possible.”
That was all the spark I needed.

I Have No Money, But I Have AI

I looked into existing solutions like Monect. It’s a great app, but it has ads unless I go premium. So let’s vibecode it — I’m getting bored anyway.

The AI sketched out a simple two‑part architecture:
1. Desktop: A Python script acting as a bridge.
2. Phone: A Flutter app.

It initially suggested emulating an Xbox controller instead of a keyboard, since my original intent was gaming. At first, it sounded cool, until I realized it required extra third-party drivers. I wanted this to be plug-and-play, so I stuck with keyboard emulation. Later I discovered that by sticking to it, I unlocked something even better: total customizability.

I wasn’t just building a gamepad. I was building a tool that could work for gaming, productivity apps, or even a DIY Stream Deck.

What surprised me most was how little code it took to get the MVP running. The Python script needed just one package (`pynput`) and less than 80 lines of code. The Flutter side didn’t even need extra dependencies.

Beyond the “F” Key: Customization & Emojis

Once the connection worked, I started iterating. The best part? The ability to customize layouts.

By customizing it, I improve the visual language. Instead of a button labeled “F,” I could label it “👊.” Instead of “M” for mute, I could use “🔇.” It makes the digital experience feel tailored and modern. You aren’t just hitting keys; you’re interacting with a custom dashboard.

The dashboard now felt alive, but I wanted to take it further. To push the limits of customizability, I moved beyond hardcoded configurations and built a JSON‑based layout engine.

This transformed the app into a modular platform. Every button is defined through a structured JSON schema, making layouts infinitely extensible. One day it’s a classic NES pad, the next it’s a control deck for video editing, all swappable in an instant.

Even more exciting, this architecture paves the way for a community‑driven ecosystem where users can share their perfectly tuned configurations as JSON files in the future.

From Terminal to GUI

I was happy with the mobile side, but the desktop side was still just a terminal window. What I really wanted was a proper desktop app. So I asked the AI for a way to turn my Python script into a GUI, and it suddenly vibecoded the script with Flet.

Flet is a framework that lets you build multi-platform apps in Python, driven by the Flutter engine. It gave me a way to keep my Python logic intact while wrapping it in a real interface. Exactly what I needed.

Unfortunately, my first experience with Flet was rough. The UI looked fine with its Material theme sure, but the app only worked in debug mode, not in release mode. (feeling a little bit deja vu here)

The artifacts were built, yet every time I tried to run them, the app crashed. This is where I learn another thing about prompting: Persistence.

It became a loop that felt almost recurring:
1. I test.
2. It crashes.
3. I copy-paste the crash report to the AI.
4. The AI tries to fix the logic.

I was the tester, and Gemini was the engineer tackling edge cases. Eventually we cracked it, like a team.

From Curiosity to Community

Since I built it using vibecode, I might as well give back to the community and make the project open source. It’s only barely working for now, but it’s a start. I’ve uploaded the Android .apk and macOS .app to the repository if you’d like to try them out.

Thanks for reading, happy coding.

GitHub - irfnyas/vgamepad: Flutter gamepad with python sever

In my previous post last year, I explored the concept of micro-frontend architecture. This time, I want to move beyond theory and discuss a technical approach that’s been validated in production. But first, let’s briefly revisit what micro-frontend architecture is.

See more: Reimagining Super App Frontend Architecture | Medium

Micro-frontend architecture

Micro-Frontend Architecture is an architectural style where independently deliverable frontend applications are composed into a greater whole.

If you’re already using a WebView inside your mobile app, you’re essentially on the path toward adopting this style. It’s important to note that micro‑frontends differ from modular architecture, which I discussed in my previous post.

Some of the key benefits that we’ve seen from micro-frontends are:

• smaller, more cohesive and maintainable codebases
• more scalable organisations with decoupled, autonomous teams
• the ability to upgrade, update, or even rewrite parts of the frontend in a more incremental fashion than was previously possible

In the context of mobile app development, this translates to:

• A single app serving as the backbone for multiple frontend services delivered via WebView
• Ability to update individual services without rebuilding the entire app
• Freedom to deploy changes instantly through the WebView, without waiting for store reviews

Why do we even need this?

Super app means multiple services live inside one app. The problem is that even minor changes to a single service will force a rebuild of the entire app. And when external partners or third parties are involved, sudden changes are inevitable, and we need to be prepared. Trust me, it happens.

This architecture will help in two critical cases:

1. Launching complex new services: services with rich menus and advanced functions evolve quickly. Micro‑frontends let them flourish independently, with faster iteration and deployment than the super app itself.
2. Displaying services through WebView with secure access: Sometimes a new service needs to be displayed through a WebView, but direct access isn’t possible because the web requires a specific token. By handling the bridging outside the super app, we enable seamless and secure integration.

How it works

Since my app are built with Flutter, I’ll illustrate this approach using two repositories: the super app and a flutter web app. The super app uses flutter_inappwebview for embedding webviews, while flutter web app leverages js_interop for JavaScript communication.

Why Flutter Web Instead of Native JS?

• Ownership: Because the service falls under the responsibility of mobile engineers, it’s better to use tools they’re already familiar with.
• Exit strategy: easier to refactor back into the super app if needed.

Example: Auth Token Management in Webview

Here’s a practical example of how authentication tokens are managed when connecting the WebView and synchronized between the super app and the WebView:

1. Super app sends access_token and refresh_token into web session storage.
2. When access_token is needed but found to be expired or null, the system checks refresh_token.
3. If refresh_token valid: frontend calls userRefreshToken. This triggers GET /profile in the app, refreshing both tokens. Updated tokens are sent back to session storage.
4. If refresh_token expired or null: the frontend calls userSignIn to open the app's login screen over the WebView. On successful login, new tokens are issued and stored. On failure, the user stays logged out.

Implementation Guide

1. Super app: Add JS handler in inAppWebviewController

inAppWebViewController.addJavaScriptHandler(
  handlerName: 'myHandlerKey',
  callback: (args) async => doSomething(args),
);

2. Web: add JS handler in js.dart, index.html, and index.js

/* lib/js.dart */

/// Needed to call JS function from dart
/// Note: function name's needs to be the same as the function on index.js
@JS()
external JSPromise? runJs(String key, JSAny? args);
/// Call this when we need to perform transaction with super app.
/// key: handler name's which we defined in inAppWebViewController
/// args: only dart primitives, iterables, typed lists, and maps are supported
Future<dynamic> runJsToDart(String key, dynamic args) async {
  try {
    JSAny? argsJs;
    if (args is List) argsJs = args.jsify();
    if (args is Map) argsJs = [args].jsify();
    if (args is String) argsJs = [args.toJS].toJS;
    if (args is num) argsJs = [args.toJS].toJS;
    if (args is bool) argsJs = [args.toJS].toJS;
    return await runJs(key, argsJs)?.toDart;
  } catch (e) {
    return null;
  }
}
/* web/index.html */
<body>
  ...
  <script defer src="index.js"></script>
</body>

/* web/index.js */

// make sure that window is ready to call handler
var isFlutterReady = false;
window.addEventListener("flutterInAppWebViewPlatformReady", function (_) {
  isFlutterReady = true;
});
// run this function to communicate with super app
// Note: function name's needs to be the same as the function on js.dart
async function runJs(key, args) {
  if (!isFlutterReady) return;
  return await window.flutter_inappwebview.callHandler(key, ...(args ?? []));
}

3. Web: Deploy your flutter web

I chose Netlify for no other reason than covid plan.
See more: When Mobile Developer meets Netlify | Stackademic

4. Super app: Show your flutter web via WebView

final webUrl = 'my_flutter_web_url';

InAppWebView(initialUrlRequest: URLRequest(url: WebUri(webUrl));

Pro tips:
Add a splash screen to your flutter web so it doesn’t display a blank space while loading inside the super app. I use Flutter Native Splash.

Performance comparison

Using Flashlight, I tested performance with a ListView containing 1.000 items. The benchmark involved scrolling all the way to the bottom. The longer the scroll duration, the greater the scroll offset, which provided a consistent way to evaluate FPS, CPU, and RAM usage under load.

Both native and WebView approaches have their pros and cons. While writing code in native Dart generally delivers better performance, WebView remains a viable alternative especially when flexibility and faster deployment matter. You can explore the test repository here.

GitHub - irfnyas/micro-fe-arch: Performance test between native dart and web

Exploring Related Implementations

I’m looking for additional references on this mobile development architecture. The closest example I’ve found is Grab’s “JavaScript to Native Bridge Communication.” However, their approach isn’t quite the same as what we’re aiming for, since Grab’s implementation focuses on one-way communication: fetching data from the mobile side to be consumed within the WebView, cmiiw.

GitHub - grab/superapp-sdk: SDK for Grab SuperApp WebView.

Closing Thoughts

Managing two repositories (one for the super app and one for the flutter web) can feel like extra effort. But in my experience, the workload isn’t that heavy once the initial setup is complete. With only a small performance trade‑off, this approach solves one of the most frustrating challenges for mobile engineers: ability to deploy anytime without waiting for store reviews.

If you’re exploring more complex architectures and this approach seems right for your project, I encourage you to give it a try. It has saved me countless headaches when deadlines are tight and sudden changes arise. And if you have questions about this architecture or mobile development in general, feel free to reach out. I’d be glad to discuss further.

Thank you for reading and happy coding.

A little while ago, I came across a tech talk titled “DX is New UX”. It immediately sparked my curiosity —DX, or Developer Experience, what exactly does that mean?

Looking closer, I realized DX isn’t really a new idea after all. It’s still about experience and productivity (as other ideas are), just not in the way we usually think.

When people talk about “experience”, the focus almost always lands on User Experience (UX). That makes sense, since UX ties directly to measurable outcomes like task success rates and, ultimately, profit.

Then, when it comes to “productivity”, they often reduce it to a simple equation: “How many developers (X) do we need in Y months to finish module Z?” But that mindset misses something crucial: the experience of the developers themselves.

Developers do care about their experience. That’s why we rely on IDEs, CI/CD pipelines, and countless other tools that make our work smoother. We just rarely take the time to stop and really think about it.

So, what is Developer Experience (DX)?

DX is the overall journey developers go through while building software. The goal is to make that journey as positive as possible.

When DX is poor, delivery slows, bugs pile up, and frustration grows. This hurts productivity, drives turnover, and makes it harder to attract new talent, ultimately dragging projects and lowering software quality.

In contrast, a strong DX allows developers to move faster, build better software, and stay motivated. It creates an environment where engineers are engaged, take pride in their work, and enjoy the process of building.

Importantly, DX isn’t about office perks or fancy amenities. It’s about removing barriers in the work itself, empowering developers to do what they do best: solve problems and create great software.

The Core Dimensions: Feedback Loops, Cognitive Load, and Flow State in Mobile Engineering

When we talk about developer experience, three dimensions always come up: feedback loops, cognitive load, and flow state. Mobile devs face the same dimensions, just with a different “flavor”.

1. Feedback Loops

Think of feedback loops as the heartbeat of development; the faster it beats, the quicker you can learn and improve. For mobile devs, this happens on two levels.

The inner loop is the immediate cycle: write some code, compile it, and see what happens on a screen. Unlike web, where you can just refresh the browser, mobile means dealing with heavy IDEs like Android Studio or Xcode, plus running apps on emulators or real devices with different screen sizes. When builds are slow or emulators laggy, that inner loop disrupts momentum. This is why features like Flutter’s hot reload are celebrated, they shorten the loop and keep developers in the zone.

Then there’s the outer loop: code reviews, testing, and deployment. On mobile, this is notoriously slow, with one extra hurdle: store reviews. Google Play or App Store review can take hours, even days. That delay stretches the time between writing code and getting it into user’s hands, adding friction that web or backend devs rarely have to face.

2. Cognitive Load

If feedback loops are about speed, cognitive load is about mental weight. Mobile devs carry a heavy backpack. Even if you’re focused on just Android or iOS, you can’t ignore the other platform if you want to keep features consistent. That means different design guidelines (Material Design vs. Human Interface Guidelines), different APIs, different languages (Swift vs. Kotlin), and tricky challenges like state or memory management.

Any tool that adds complexity, like a clunky cross-platform framework that doesn’t fully cover native APIs, or a CI/CD pipeline that behaves differently across platforms, just makes the backpack heavier. But tools that reduce complexity can feel like a breath of fresh air. For example, a solid CI/CD setup like Codemagic can help abstract away repetitive release tasks, easing the mental load.

3. Flow State

Flow is the pinnacle of developer productivity, that moment when everything clicks and you’re completely absorbed in the work. But for mobile devs, flow is fragile. Switching between IDEs, languages, docs, and the very different mental models of Android and iOS makes it harder to stay in the zone. Add in long builds, emulator slowdowns, or frequent context switching between tasks, and flow shatters fast.

This is why practices like unified design systems (to reduce platform context switching), and feature flagging tools (to test features without app store delays) are so valuable. They help protect flow and keep engineers focused on solving problems instead of fighting their environment.

These Dimensions Are Foundational

Together, these three dimensions shape the daily reality of mobile devs:

• Shorter feedback loops → more creativity.
• Lower cognitive load → clearer thinking.
• Stronger flow → deeper focus and better quality.

Improving mobile DX starts with getting these foundations right. Of course, once you start talking about mobile, one question always comes up…

What about cross-platform?

Cross-platform frameworks promise to make life easier, and to some extent they do. By reducing context switching, developers can focus on a single codebase instead of juggling both Android and iOS. But the trade-offs are real:

• You’ll likely need to learn a new language (Dart for Flutter, JS for React Native).
• Native skills never fully disappear. You still need Kotlin or Swift when bridging to platform-specific APIs.
• Yes, you can use lighter editors like VS Code, but you still have to run apps on emulators or real devices, with all the same slowdowns.
• And at the end of the day, the app store rules don’t go away. You’ll still face Google Play and App Store reviews just like native developers.

Cross-platform makes some things easier, but not everything. It smooths out some pain points, especially around maintaining two codebases, but many of the core challenges of mobile DX (slow feedback loops, high cognitive load, fragile flow) are still very much there.

Surely AI will helps?

AI is already making their mark on software development. Companies like Google and Microsoft report that nearly a third of their new code is AI-generated, with some teams seeing productivity boosts of 50% or more.

But speed isn’t the whole story. Alongside the gains, studies show AI can also introduce deeper issues like architectural flaws, privilege problems, and hidden vulnerabilities that often slip past reviews.

In mobile engineering, things get even trickier. For AI to truly become a game-changer in mobile DX, it needs to be useful in a few key areas:

• Complex build setups: Mobile build systems are known for slowing developers down. If AI could reliably manage Gradle, Android Manifest, Info.plist, and Xcode configs, it could dramatically shorten the cycle from “write code” to “see it running” making iteration smoother and faster.
• Architectural context: Mobile projects are more than just isolated files. AI has the potential to reduce the mental overhead by understanding the bigger picture: state management, navigation flows, native bridges, and generating code that naturally fits into existing architectures.
• UI and UX nuance: If AI learns to handle responsive layouts, state-driven UIs, and platform-specific design guidelines, it could free developers from tedious layout fixes and let them focus on the creative side of building.

The future of AI in mobile engineering goes beyond just writing code. When AI can support smoother feedback loops, lighten cognitive load, and protect flow, it won’t just make us faster — it will make the experience itself better.

Environment, Career, and the DX Holding It Together

Being a mobile devs comes with some very specific quirks. If you’re building for iOS, you’re locked into macOS hardware, no way around it. That’s a big constraint (and cost) for both engineers and organizations. On top of that, the IDEs we use are powerful but heavy. They demand high-performance machines, and even then, builds can feel painfully slow.

The industry is pushing toward cloud-based development environments like GitHub Codespaces and Firebase Studio to make setup easier and onboarding smoother. But for mobile, those tools aren’t quite there yet, at least for me.

Beyond the technical environment, there’s also the question of career trajectory. Many mobile specialists run into what’s often called the frontend ceiling. The idea is that engineers who go deep into mobile (or frontend in general) can find it harder to reach top technical leadership roles like CTO. Why? Because their work is often perceived as being “far from the core”: things like scalability, architecture, and systems design, which are seen as central to running large-scale tech organizations.

That perception creates a long-term DX challenge: how do you keep senior mobile devs motivated when the path to the very top seems narrower? Some move into management, others expand into full-stack, but many struggle with this ceiling.

This is where DX shows its true value: it’s more than just a productivity boost. A well-designed DX can make the day-to-day work feel meaningful, keeping senior specialists motivated. In the end, great DX transforms mobile engineering from a frustrating grind into a craft worth sticking with.

Measuring and Diagnosing Mobile DX Friction using Hybrid Measurement Framework

The best way to understand DX is through a hybrid framework: a mix of quantitative data and real feedback from developers about their everyday experience.

Why both? Because numbers can lie. A CI system might proudly report a “fast” 10-minute build, but if developers perceive it as painfully slow, then it is painfully slow. On the flip side, if you only rely on surveys, you risk chasing complaints without understanding the technical root causes.

DORA Metrics for Quantitative Analysis

The DevOps Research and Assessment (DORA) metrics are the industry standard for measuring software delivery performance. They show how well teams balance speed and stability through four key metrics:

• Deployment Frequency (DF): how often code reaches production.
• Lead Time for Changes (LTFC): how long a commit takes to go live.
• Change Failure Rate (CFR): how often releases cause issues.
• Mean Time to Restore (MTTR): how quickly you recover from a failure.

They’re super useful, but here’s the thing: mobile is different.

• Deployment Frequency: Frontend (web) and backend can deploy to production anytime they want. Mobile? You’re gated by store reviews. Instead of counting daily production pushes, it makes more sense to track how often you ship builds to testers and how frequently you release to the app stores.
• Lead Time for Changes: On mobile, LTFC is messy. A single commit must go through code review, CI builds, distribution to testers, and then store review, adding hours or even days.
• CFR & MTTR: Still relevant, but cycle times are longer on mobile, so interpretation needs extra care.

And remember: DORA metrics are lagging indicators. They tell you there’s a problem, but not why. If LTFC is high, the real issue is usually friction in the inner loop: the cycle of coding, building, testing. That’s where you need more mobile-specific metrics, like:

• Local Build & Compilation Time: clean vs. incremental build times.
• Test Suite Execution Time: how long it takes to run unit/UI tests locally.
• Emulator/Simulator Boot Time: a frequent task that can break a developer’s flow.
• App Performance Metrics: key user-facing measures like startup time (TTID) and rendering smoothness (dropped frames/jank).

The Voice of the Developers as Qualitative Insights

Metrics tell you what’s happening. Developers tell you why. Structured surveys, if done right, can map feedback directly to DX dimensions:

• Feedback loops: “How quickly can you test local changes?”
• Cognitive load: “How confident are you making changes to the codebase?”
• Flow state: “How easy is it to get uninterrupted focus time?”

Other sentiment checks include:

• Developer Satisfaction (DevSat): Overall satisfaction with tools and processes.
• Employee Net Promoter Score (eNPS): Would you recommend this place to a friend?
• Retention rates: The slowest but clearest signal. If people keep leaving, DX is failing.

Averages hide pain. The problems of a senior mobile are very different from those of a senior backend. That’s why qualitative data must be segmented by team, platform, and seniority. Otherwise, you risk missing hotspots where DX is quietly draining morale.

A healthy DX program isn’t about one-off surveys or dashboards, it’s about building a sustainable loop of measurement and dialogue. A solid program usually includes:

• Establishing a baseline for key metrics.
• Running quarterly surveys to track sentiment.
• Continuously monitoring system data.
• Setting up real-time feedback channels (Slack, forums, 1:1, etc).

This program keeps DX visible and gives engineers a voice in shaping it.

Why DX Matters

Mobile engineering will always come with unique constraints: from store reviews to heavy toolchains and platform quirks. But those constraints don’t have to define the developer experience. The real opportunity is in reducing friction, protecting flow, and listening to the people who build. If we want better apps, we need to start with better DX. Because great developer experience is the foundation of great software.

Thanks for reading, happy coding.

Selama lebih dari lima tahun berkarier, saya beruntung memiliki pengalaman membantu rekan-rekan yang baru memulai perjalanan di dunia engineering.

Dalam satu kesempatan, saya menjadi mentor bagi seorang intern. Di kesempatan lain, saya dipercaya membimbing sesama engineer agar lebih mandiri dalam mengambil keputusan teknis. Meski konteksnya berbeda, tujuannya sama: mendukung mereka menjadi mobile engineer yang kompeten.

Tapi, seperti apa kompetensi itu terlihat dalam keseharian? Setelah banyak berdiskusi, membaca literasi, dan mengamati para engineers yang saya anggap kompeten, muncul sebuah pola — hal yang saya perhatikan saat menilai kemampuan seorang mobile engineer.

1. Environment Setup

Yang pertama adalah cara dia melakukan Environment setup. IDE apa yang digunakan, bagaimana version controlnya, dan tech stack apa yang dipilih.

• Tidak ada IDE yang sempurna, tetapi seorang engineer yang kompeten punya alasan kuat dalam memilih alat yang digunakan.
• Pemahaman mendalam tentang konsep versioning, terutama Git, adalah mutlak. Ini bukan hanya tentang kolaborasi, tetapi juga narasi yang ingin seseorang bawa dalam proses menulis baris kode hingga menjadi sebuah aplikasi.
• Mencoba berbagai stack adalah hal yang diharuskan, tetapi kita perlu memiliki alasan dari pilihan yang digunakan.

2. Development Process

Yang kedua adalah proses Development. Mulai dari arsitektur kode, strategi debugging & testing, hingga pendekatan terhadap git branching.

• Arsitektur mempengaruhi seberapa fleksibel kode yang ditulis saat dibenturkan dengan perubahan. “Satu-satunya yang konstan adalah perubahan”.
• Debug & Test Strategy yang matang mencerminkan seberapa dalam pemahaman seseorang terhadap kode yang ditulis serta seberapa percaya diri terhadap hasil kerjanya.
• Git branching strategy juga perlu diperhatikan. Jika memang bekerja sendiri dan butuh iterasi cepat, apa membuat banyak branch masih relevan?

3. Deployment Strategy

Yang terakhir adalah strategi Deployment. Meliputi penerapan CI/CD, proses publikasi aplikasi ke store, serta pemanfaatan tools monitoring.

• Memasang CI/CD memang lumrah, tapi terkadang build manual dan kirim Google Drive lebih murah. Prinsip idealis seseorang akan diuji saat dipertemukan limit bulanan.
• Belum lengkap ilmu seorang mobile engineer jika belum pernah melewati proses rilis aplikasi ke store.
• Pengembangan tidak berhenti setelah rilis. Tools monitoring dibutuhkan untuk memahami bagaimana user berinteraksi dengan aplikasi dan apa yang bisa diimprovisasi.

Jika dalam ketiga aspek ini seseorang bisa menjelaskan pilihannya tanpa ragu, maka dirinya layak disebut sebagai mobile engineer yang kompeten.

Dan jika kamu sedang dalam proses menuju ke sana — teruslah berjalan. Kompetensi tidak dibangun dalam sehari, ia tumbuh dari keputusan-keputusan kecil yang konsisten.

Thanks for reading, happy coding.

What is a Super App?

A super app is a single platform that integrates a variety of services, allowing users to complete multiple, diverse tasks without switching between separate applications. Each feature within a super app is modular and could function independently as a standalone application.

One example of a super app is Sapawarga, a government-backed app launched by the West Java provincial government in Indonesia. Users can access public services, file taxes, report issues, find local job listings, order tickets for gallery visits, and more — all within a single app.

How will you build a super app?

Building a super app requires “super” thought. Imagine this: we’re tasked with building a new Super App — a single application that offers multiple services, combining everything our users need into one seamless experience. This means:

• The app will serve as a hub for multiple services.
• Users will only need to install this app to access all our services.
• It must accommodate both internally developed services and those created by external partners.

As engineers, the default approach to building an app is using monolith architecture. In the context of a super app, this usually translates to creating a new folder within the codebase every time a new service is introduced.

Sure, we can develop this way. However, as the app grows in complexity, this approach starts to reveal significant drawbacks:

1. Slower Updates for Individual Services
   When all services live in a single codebase, releasing updates often involves bundling changes for multiple services together. This bulk update strategy may minimize the overhead of App Store rollouts, but it comes at the cost of being agile. A small update for one service is delayed because it’s tied to unrelated changes in other services.
2. Delays in Delivering Features or Hotfixes
   When updates are slow, so is the delivery of new features or critical hotfixes. This delay can frustrate users who expect fast responses to issues or new functionality. Over time, the inability to address issues quickly erodes user trust and satisfaction.
3. Negative Impact on User Experience and Public Perception
   Poor user experience caused by delays in updates reflects directly on the perception of our app — and by extension, our company. Users may view us as unresponsive or outdated, which could lead to disengagement and loss of market share in a competitive landscape.

Now, we think, “Alright, let’s adopt a modular architecture.”

We will refactor the service folders into independent modules, treating each as its own package and importing them as dependencies into the main codebase. It feels like a cleaner, more scalable solution. We publish the app, confident that we’ve addressed the challenges.

But then, when it’s time to update just one service, we find ourselves facing the same limitations. Despite the modular structure, the core bottlenecks remain unchanged. The result? We’re back at square one, wondering if there’s a better way forward.

How about Microservices, but for Frontend?

When it comes to backend development, one term often stands out: microservices. While the concept is similar to modular architecture, the key difference is that each service in a microservices model runs independently.

In the context of frontend development, we can draw a parallel to micro frontends architecture. While the concept is the same — breaking down large, monolithic apps into smaller, independent pieces — the difference lies in how these smaller pieces are integrated into the frontend.

If you have already developed an app that uses a webview to support a service, chances are you’ve already implemented micro frontends in some capacity. This approach allows services to be updated on demand, without rebuilding the entire app. It would be as if the tourism service operated as its own standalone app, allowing updates to be deployed without building the entire app codebase.

However, this doesn’t mean all services should rely on webviews. While webviews enable faster updates, they lack the seamless performance of native apps. Features like GPS, push notifications, and other mobile functionalities often require native coding to work effectively. Moreover, an app overloaded with webviews may face rejection from App Store.

The key is mastering the balance: knowing when to build a service natively for performance and functionality, and when to use a modular or webview-based approach for flexibility. Consider building a service modular if it meets these criteria:

1. The service is unlikely to require native mobile features.
2. The service is heavily reliant on external partners.
3. The service has a higher priority, requiring faster updates or independent scalability.

If a service checks all these three points, then it’s an excellent candidate for the next modular implementation.

Exploring the Technical Challenges Ahead

As we adopt a micro frontends architecture to handle the increasing complexity of a Super App, two key challenges often arise: consistency and communication.

1. Consistency Across Services

To deliver a seamless user experience, all services must follow consistent design principles across the Super App. This involves not only ensuring a unified look and feel but also maintaining visual and functional consistency, regardless of the underlying technology.

Performance consistency is equally critical. While modules using webviews may experience reduced performance, it’s important to ensure that the difference remains minimal. The goal is to create an experience where performance fluctuations are almost imperceptible to the user, ensuring smooth interaction across all modules.

State consistency is another essential element. For instance, if a user has signed in through the main app, all modular services should recognize and reflect this signed-in state. This sync goes beyond design and performance — it extends to how information flows between services, which brings us to the next challenge: communication.

2. Communication Between Modules

Consider a Super App where the main app is built using Flutter Mobile, while its modules use various frameworks like Flutter Web and VueJS. These modules must communicate and share state with the main app seamlessly, despite being built with different technologies.

For modules presented through webviews, communication between the Super App and individual modules can be tricky. One strategy we can use is to create a communication bridge using JavaScript to pass data between the app and the module. In this case:

• The Super App sends data to the module via JavaScript handler, which is intercepted by a listener in the module.
• The module then sends data back to the Super App, which is handled by a handler in the main app.

This process creates a bidirectional communication flow, ensuring that the main app and its modules stay in sync. The data flow might look like this:

By addressing consistency and communication challenges effectively, we can ensure a smooth, unified experience across all modules, making the Super App not only functional but also capable of delivering high-quality user experiences.

The Takeaway

To build a scalable Super App, adopting a micro frontends architecture can provide significant benefits. By ensuring that each module operates independently while maintaining frontend consistency, performance, and seamless communication, you can create an app that evolves quickly and continues to deliver high-quality user experiences, even as you add more services.

Thank you for reading and happy coding.

Backstory

Have you ever been in these situations?

You wander over to the domain of your frontend colleague, take a peek at their Netlify setup, and see this:

Why do they get all the free perks while we squeeze every last minute to build an artifact?

The Netlify Plugin

Netlify already supports Flutter Web using this plugin, but how can we extend it to support Flutter Android? If we check out the plugin’s code, we can see it’s cloning the Flutter SDK and adding the flutter command to the PATH:

...
console.log('⚡️ Downloading Flutter Stable SDK')
await run('git', [
  'clone',
  'https://github.com/flutter/flutter.git',
  '-b',
  targetChannel,
  process.env['HOME'] + '/flutter',
])
console.log('✅ Flutter SDK downloaded')

console.log('🪄 Adding Flutter to PATH')
process.env['PATH'] = process.env['PATH'] + ':' + flutterBinPath
...

Since we already have the Flutter SDK, what we need to add for building an Android artifact are Java and the Android SDK. So, let’s download both and add them to the PATH:

...
/*
  Install Java
*/
console.log('☕️ Installing Java')
await run('wget', [javaDownloadUrl, '-O', 'jdk.tar.gz'])
await run('mkdir', ['-p', javaPath])
await run('tar', ['-xzf', 'jdk.tar.gz', '-C', javaPath, '--strip-components=1'])
process.env['JAVA_HOME'] = javaPath
process.env['PATH'] = process.env['PATH'] + ':' + javaPath + '/bin'
console.log('✅ Java installed')

/*
  Install Android SDK
*/
console.log('📥 Fetching latest Android cmd-line tools URL');
let androidSdkDownloadUrl;
try {
  androidSdkDownloadUrl = await getAndroidSdkDownloadUrl();
} catch (error) {
  console.error('Failed to get the tools download URL:', error);
  return build.failBuild('Could not fetch the Android SDK command-line tools URL');
}
console.log('✅ Latest URL:', androidSdkDownloadUrl);

console.log('📱 Installing Android SDK')
await run('mkdir', ['-p', androidSdkPath])
await run('wget', [androidSdkDownloadUrl, '-O', 'cmdline-tools.zip'])
await run('mkdir', ['-p', `${androidSdkPath}/cmdline-tools`])
await run('unzip', ['cmdline-tools.zip', '-d', `${androidSdkPath}/cmdline-tools`])
await run('mv', [
  `${androidSdkPath}/cmdline-tools/cmdline-tools`,
  `${androidSdkPath}/cmdline-tools/latest`,
])
process.env['ANDROID_HOME'] = androidSdkPath
const env = {
  ANDROID_HOME: androidSdkPath,
  PATH: `${androidSdkPath}/cmdline-tools/latest/bin:${androidSdkPath}/platform-tools:${process.env['PATH']}`
}
await run(`${androidSdkPath}/cmdline-tools/latest/bin/sdkmanager`, [
  'platform-tools',
  'platforms;android-34',
  'build-tools;34.0.0',
], { input: 'y\n', env })
console.log('✅ Android SDK installed')

/*
  Install Flutter
*/
console.log('⚡️ Installing Flutter SDK')
const targetChannel = 'stable'
await run('git', [
  'clone',
  'https://github.com/flutter/flutter.git',
  '-b',
  targetChannel,
  process.env['HOME'] + '/flutter',
])
process.env['PATH'] = process.env['PATH'] + ':' + flutterBinPath
console.log('✅ Flutter SDK installed')
...

For easier use, I created a new Netlify plugin called netlify-plugin-android. You can check out the full code at the link provided.

Installing the Plugin

Keep in mind that this approach may only work with a newly created Flutter Android template, as the goal here is to demonstrate a proof of concept.

Please install this plugin from the Netlify app.

1. Add the following to netlify.toml:

[[plugins]]
  package = "/plugins/netlify-plugin-android"
[build]
  command = "flutter build apk && flutter build web"
  publish = "build/web"

2. Add the following package files to plugins/netlify-plugin-android:

plugins
  |__ netlify-plugin-android
      |__ src
      |   |__ index.js
      |
      |__ manifest.yml
      |__ package.json

3. Add the following to app/build.gradle for building APK:

android.applicationVariants.all { variant ->
    variant.assemble.doLast {
        def outputFile = variant.outputs.first().outputFile
        copy {
            from outputFile.parent
            into file("${rootDir.parent}/build/web")
            include outputFile.name
        }
    }
}

4. Trigger a new deploy. Your new artifact will be available at https://*.netlify.app/app-release.apk

My Take on Building with Netlify

• The build speed is comparable to Codemagic. My project’s build time on Netlify was 3m 52s, while on Codemagic it was 3m 46s.

• While you’re at it, consider building the Flutter Web version too, and add a homepage (at least a splash screen) so it doesn’t show a 404 page.
• Codemagic remains a better option if you can afford the premium plan or rarely hit its build time limit.

Feel free to ask questions or discuss on Github at irfnyas/netlify-plugin-android. Thank you for reading and happy coding.

Stackademic 🎓

Thank you for reading until the end. Before you go:

• Please consider clapping and following the writer! 👏
• Follow us X | LinkedIn | YouTube | Discord | Newsletter | Podcast
• Create a free AI-powered blog on Differ.
• More content at Stackademic.com

When Mobile Developer meets Netlify was originally published in Stackademic on Medium, where people are continuing the conversation by highlighting and responding to this story.

1. Translating for upper management

Keep communication non-technical and easy-to-understand. They’re very busy people. So, all the information they need is:

• Project length
• Project cost
• Potential problems
• The pros and cons of different approaches
• And so on

Sometimes, you’ll also make a decision yourself and then need to sell your solution to upper management. This requires explaining:

• What needs to be done
• In what way
• And why it’s the best option

2. Communicating precisely and concisely

This is the information your peers need to decide how they want to proceed an issue:

• What’s happening
• Why it happened
• How to stop it as soon as possible
• The benefits and risks of possible solutions

Just like upper management, your team members and peer managers don’t have time to waste. You have to communicate the essentials, which means:

• Saying what you need quickly and accurately
• Making sure the other person or people understands you
• Asking something clearly so the other person or people know how to accurately respond

Also, make it a habit to minimize unhelpful conversations and keep meetings on point.

3. Speaking to people in their own language

For example, project managers (PMs) won’t know technical speak, but engineers prefer technical precision. So, you have to adjust your language depending on which one you’re talking to.

Use things they care about to help get aligned on what needs doing. If I’m talking to someone who loves video games, I use games to describe what I want them to do.

4. Helping people understand each other

This is especially necessary when the team members come from completely different worlds, like designers, engineers, and PMs. This isn’t easy, but it’s worth doing, and it requires:

• Understanding everyone’s perspectives
• Learning everyone’s languages
• Explaining both sides
• And confirming everyone’s on the same page

5. Regulating emotions during conflict

People get emotional. You have to bring their emotions back to normal first, so they’ll be ready to listen to anyone. We do this in these ways:

1. Let them talk, they will have a grievance to share, and you won’t get anything in until they’ve run out of steam
2. Ask them questions, to confirm that you’ve understood their grievance properly
3. Add your own perspective, or add the perspective of the other person, doing both after they see that you’ve taken the time to understand them

After these steps, you can model skills like apologizing or accepting apologies with grace.

The key is remembering that you have to address conflicts early before they make the team an unpleasant place to be and cause good people to leave.

“Talking well takes work, but the results are worth the effort”

Sebagai seorang flutter developer, tentu kamu tidak asing dengan pub.dev dan segala lika-likunya. Menggunakan package memang menyenangkan, tapi kadang kala tidak seindah kenyataan. Beberapa masalah yang umum kita temukan:

• Package sudah deprecated
• Package belum memiliki fitur yang dibutuhkan
• Package tidak memiliki dokumentasi yang lengkap
• Tidak ada package-nya 😅

Tetap tenang, ada beberapa solusi yang bisa kamu coba untuk memperbaiki situasi ini.

1. Buat issue baru (Level: Beginner)

Langkah pertama yang bisa dilakukan adalah masuk ke halaman repository-nya dan membuat issue baru.

Bagaimana kalau kita tidak ada waktu untuk menunggu fix dari owner repository? Jika kamu yakin dengan kemampuan coding-mu, kita bisa mencoba solusi yang kedua.

2. Fork Repository (level: intermediate)

Kita akan melakukan fork repository dan memperbaiki packagenya sendiri. Solusi ini relatif lebih mudah ketimbang membuat package dari awal, tapi umumnya hanya dilakukan sebagai temporary fix.

Jika sudah beres melakukan perubahan, push kembali ke repository. Langkah berikutnya adalah menambahkan spesifik git pada dependency di pubspec.yaml project yang menggunakan package ini. Misal, hasil forked package focus_detector saya ada di branch utama https://github.com/irfnyas/focus_detector.git, maka penulisannya nanti akan menjadi:

dependencies:
  focus_detector:
    git: https://github.com/irfnyas/focus_detector.git

Info lebih lengkap bisa baca di sini.

Nah, sekarang bagaimana kalau ternyata kamu tidak menemukan package yang dibutuhkan? Jika tertarik, kamu bisa membuat package sendiri.

3. Membuat package sendiri (level: advanced)

Membuat package tidak sesulit kelihatannya. Untuk proses publikasi sebenarnya mudah, yang sulit adalah kompleksitas dari package itu sendiri.

Pertama kamu perlu membuat package project-nya. Kamu bisa melakukan ini menggunakan Flutter Wizard di Android Studio atau menggunakan command:

flutter create --template=package {package name}

Setelah project dibuat, tulis kode fungsi dalam folder lib. Lebih direkomendasikan jika kamu bisa menambahkan flutter test dan example project. Kamu bisa membuat example project dengan menggunakan command:

flutter create example

Jangan lupa meng-update CHANGELOG.md, LICENSE.md, dan README.md. Beberapa web yang bisa membantu kamu untuk hal ini:

• keepachangelog.com: Rekomendasi cara menulis changelog yang baik.
• choosealicense.com: Jika tidak yakin mau menggunakan license mana.
• pandao.github.io: Membantumu melihat preview readme.

Sekarang package siap untuk publish. Kamu bisa menjalankan command flutter pub publish langsung, tapi lebih baik menggunakan --dry-run dahulu untuk memastikan package bebas dari warnings dan errors. Jadi, command yang perlu dimasukkan:

flutter pub publish --dry-run
flutter pub publish

Selamat, package-mu akan segera muncul di pub.dev 🎉

Jangan puas dulu, artikel ini hanya membahas langkah minimal untuk mempublikasikan package. Masih ada cara untuk membuat package-mu lebih baik yang akan kita bahas di kesempatan lain.

Silakan isi kolom komen jika ada pendapat atau pertanyaan. Thanks for reading and happy coding.

Semua Package akan ‘deprecated’ pada Waktunya was originally published in JDS Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

This year, I got myself homework at the year-end holiday from my senior. Really, how thoughtful of him. Anyway, the tasks are to find any design inspiration, create an app with flutter from it, and write its story as a portfolio.

Because I’m also a thoughtful person just like him, my first idea is to create an app which shows quotes. While searching for a design, I saw this. It catches my attention by its minimalistic yet full of emotion because of the colour filter and the photo as the background.

My Senior loves to take a photo with his phone, so my final idea is to create a camera app where it shows a colour filter and a randomised/editable quote in the centre of the screen.

The development went as smoothly as it could. It shows the camera preview, colour filter, and quote. Now is the time for the screenshot functionality. I wrote the code, and then this happened:

The camera preview is not in the screenshot. Don’t worry, tetap tenang (keep calm). Someone or the guy who create the screenshot dependencies might know the workaround:

Fine, I’ll do it myself.

/*
  assuming you are using dependencies
  camera: ^0.10.1
  screenshot: ^1.3.0
*/

// 1. You need to take the picture of camera preview and save it as File
await cameraController
        .takePicture()
        .then((value) => cameraFile = File(value.path));

// 2. Show the taken picture in Image.file()
Image.file(cameraFile),

// 3. do screenshot
await screenshotController.capture();

// Note: If the camera preview still not showing in screenshot,
// try to add a delay around 1 sec between 
// cameraController.takePicture() and screenshotController.capture()

If you have any questions, please don’t hesitate to contact me or create an issue in the GitHub repository. Thank you for reading, happy coding.

GitHub - irfnyas/qshot: Shot your moment with quotes. Powered by Flutter.