DEV Community: Nexa Tech

AI can design an app now. Are designers redundant?

Nexa Tech — Sat, 10 Oct 2026 01:19:01 +0000

AI can now draft a screen, write the button labels, and turn a sketch into a clickable prototype in minutes. So here is the question every designer has quietly asked at 2 a.m.: are designers now redundant?

To answer it honestly, we have to separate two things people often mix up: producing design artefacts and doing design.

AI automates the output of design—screens, copy, prototypes—not the decisions behind it.
When producing a draft becomes cheap, the bottleneck moves to judgement, context, and validation.
Tasks inside the designer’s job will disappear. The job itself will move up a level.
The designers at real risk are the ones whose work stops at the artefact.

AI can make the options quickly. Design is deciding which one is right for the people who will use it.

What design actually is

From the outside, design looks like making screens. In practice, a screen is the last and smallest part of the work. A typical app feature passes through five layers:

Problem: Who is the user, what are they trying to do, and what gets in their way?
Priority: Of everything we could build, what matters first, and what do we leave out?
Flow: In what order do things happen, and what happens when something goes wrong?
Interface: Layout, components, hierarchy, copy, and visual style.
Validation: Does it work for real people, in real conditions? What do we change?

Each layer depends on the one before it. A beautiful interface built on the wrong problem is still a failure—just a better-looking one.

What AI is actually good at

Map today’s AI tools onto those layers and a clear pattern appears:

Where AI is strong	What it helps with
Interface	Drafting layouts, generating variations, writing microcopy, applying a design system, and building quick prototypes.
Problem and validation	Summarising reviews and interviews, grouping feedback, and spotting patterns across lots of text.
Priority and flow	Still weak at choosing trade-offs, deciding what to cut, and knowing which edge case will hurt users.

AI is strongest at the layer that is easiest to see and weakest at the layers that decide whether a product succeeds. That is why it can look like it replaces designers, while in practice it replaces only part of what they do.

Four reasons designers aren’t redundant

1. Cheap drafts make choosing more important

When one screen took a day, a team might compare two options. When AI produces twenty in a minute, someone has to decide which one is right—and why.

Abundance does not remove the need for judgement; it multiplies it. The scarce skill is no longer making options. It is choosing well between them.

2. AI doesn’t know your user’s context

A model learns from patterns across millions of apps. It has never stood in a supermarket aisle holding a basket in one hand and a phone in the other, which is exactly the situation our Ingredient Scanner has to be designed for.

Context like that changes where buttons go, how big text is, and what appears first. It comes from observing users, not from training data.

A real use case has constraints that a generic prompt cannot see: one hand is busy, the aisle is distracting, and the answer needs to be immediate.

3. AI drifts toward the average

Generative models produce the most likely answer. In design, the most likely answer is the most common one. That is useful for standard patterns such as login screens or settings, but it is the opposite of what makes a product memorable.

Differentiation is a deliberate choice to not do the average thing, and someone has to make it.

4. Someone has to own the result

If a flow confuses older users, if a screen fails accessibility, or if a dark pattern slips into checkout, the question is not “which tool generated this?” but “who approved it?”

Responsibility for the user’s experience cannot be delegated to a model. It needs a person who notices, cares, and can explain the decision.

AI is great at making options. Design is the job of choosing.

Good review connects interface choices to evidence: what users said, what they can access, and what the product needs to achieve.

The strongest counter-argument

To be fair, the case for “designers are redundant” is not silly. It goes like this: most apps do not need original design. They need a decent, standard interface, fast. AI already does that well enough.

This is partly true. For internal tools, simple prototypes, or early MVPs, a developer with a good design system and an AI tool can ship something perfectly usable without a dedicated designer. Some design work—resizing assets, making variants, or writing first-draft copy—will shrink for real.

But that argument proves something narrower than it claims. It shows that certain design tasks are being automated, not that the design role is. As soon as a product competes on experience, serves a specific audience, or carries real risk, the upper layers—problem, priority, flow, and validation—come back. Those are human work.

What actually changes for designers

What becomes more valuable:

User research and observing real behaviour
Framing problems and setting constraints
Building and maintaining a strong design system that AI can follow
Critiquing and editing, not just creating
Accessibility, ethics, and edge cases

What becomes less valuable:

Producing screens from a clear spec
Making many variants by hand
Pixel-perfect mockups that are never tested
Design work that stops at the hand-off

How we work with AI at Nexa Tech

Our rule is simple: AI speeds up the parts we can easily check, and people own the parts that need judgement.

Research: AI groups app-store reviews and feedback into themes; a designer reads the raw quotes before drawing conclusions.
Exploration: AI generates many layout options; the team picks a direction based on the user’s context, not what looks best in isolation.
Production: AI drafts screens from our components and tokens; a designer fixes hierarchy, spacing, and states.
Validation: Real users test the prototype. AI can predict behaviour, but only people can show it.

Start with your design system. AI follows whatever rules you give it. A clear, documented design system turns its output from “generic app” into “close to ours,” and makes every review faster.

So, is the designer redundant?

No. But the designer who only pushes pixels might be.

AI has made the visible part of design cheap. That forces the invisible part—understanding people and choosing what to build for them—into the spotlight. Designers who move up to that level will not be replaced by AI. They will be the ones deciding how to use it.

Full Story: https://www.nexateam.dev/blog/ai-in-app-design

AI in software development: turn change into an advantage

Nexa Tech — Fri, 09 Oct 2026 15:06:09 +0000

"Will AI replace developers?" is the wrong question. The better one is: how should we change the way we work?

AI's biggest gift isn't faster typing. It gives teams more room to understand the problem, test their decisions, and build products people actually want to use.

TL;DR

AI should extend what your team can do, not let anyone skip the thinking.

Start with repetitive work where the result is easy to check.

Put guardrails in place before you speed up: testing, security, and review apply to AI output too.

Measure product outcomes, not lines of code.

The work hasn't shrunk. It has moved.

An engineer can now ask AI to sketch a feature, explain an unfamiliar codebase, write test cases, draft API docs, or summarise a production incident. Tasks that used to break a whole afternoon of focus now take minutes.

That doesn't make the engineer's job smaller. It moves the most important work to the front:

choosing the right problem
setting the right constraints
weighing the trade-offs
owning the experience users end up with

AI can generate options. People still have to choose the one worth building.

The trap: speed that turns out to be debt

AI-generated code can look completely convincing while resting on a bad assumption, missing an edge case, or calling an API that no longer fits. A team that only tracks how much faster it ships is easy to fool. What feels like productivity can be technical debt that shows up later.

✅ Use AI as a lever

Ask it to state its assumptions and risks before it proposes a solution
Review the diff, the tests, and the user-facing behaviour like any other change
Save the prompts, decisions, and results that worked so the whole team learns from them

❌ Don't use AI as a shortcut

Shipping generated code you don't understand
Pasting customer data or secrets into tools that haven't been approved
Letting fast code generation replace discovery and product thinking

How we adopt AI at Nexa Tech

1. Start small
Pick repetitive work that's easy to verify: unit tests for pure functions, pull-request summaries, fixtures, or turning an issue into a checklist. The value is real and the risk is low.

2. Set guardrails first
Decide which data never leaves your systems, who reviews AI output, what the minimum test coverage is, and when you roll back. Clear rules are what let a team use AI with confidence.

3. Give AI context, not just prompts
AI does better work when it knows your conventions, your architecture, and your definition of done. Keep the README, decision records, good examples, and test suite up to date. They help new teammates and AI alike.

4. Measure outcomes
Track lead time, post-release defects, review time, and user satisfaction. If a tool adds lines of code but none of these numbers improve, it hasn't given you a real advantage.

The skills that are worth more now

	Skill	Why it matters
01	Asking better questions	Breaking a vague problem into constraints, success criteria, and steps you can verify.
02	Technical judgement	Spotting the answer that is almost right but doesn't fit your system, your data, or your users.
03	Systems thinking	Weighing product, operations, security, and experience together so the decision holds up over time.

Make AI a team advantage, not a personal trick

The strongest team isn't the one with the most AI tools. It's the one that turns what each person knows into something the whole team can use: prompt patterns for familiar tasks, review checklists, component libraries, reliable tests, and regular, honest talks about what worked and what didn't.

💡 Pair before you automate
For the first few weeks, let AI suggest and let people decide. Note where it saves time, where it adds noise, and why. Once you have that evidence, you'll know what is safe to automate.

One question to ask every time

Before accepting any AI output, ask:

"If AI weren't here, how would I check this?"

If you can still read the code, run the tests, inspect the data, and explain the choice to a teammate, AI is making you stronger. If you can't, it is hiding a gap.

AI isn't the enemy of good engineering. It raises the bar. Good engineers will be judged less by how fast they type and more by how well they turn complex problems into products people can trust.

How is your team using AI in its workflow? What has worked, and what hasn't? Let me know in the comments 👇

Originally published on the Nexa Tech blog.

Building quishing protection into a React Native QR scanner (no server needed)

Nexa Tech — Fri, 09 Oct 2026 12:04:31 +0000

ScanQR is on App Store and Google Play. I'd love feedback, especially regional phishing patterns or payment formats I should add next. 🙏

Most QR scanner apps do one thing: decode the string and throw it at the browser. That's precisely what quishing (QR phishing) relies on. A sticker over a parking meter, a fake "pay here" code on a restaurant table, a parcel notice with a code. You can't hover over a QR code to preview the link.

I'm building ScanQR, a React Native scanner. For this release I wanted it to understand what it scans before the user taps anything. Here's how two parts of that work: link safety checks and payment QR parsing.

1. Link safety: offline heuristics first

I didn't want every scan to need a network round trip, so the first pass is pure string analysis that runs instantly and offline:

export type RiskReason =
  | 'shortener'       // bit.ly, qrco.de… hides the real destination
  | 'punycode'        // xn-- labels: look-alike characters
  | 'ip_host'         // http://185.23.x.x/login
  | 'userinfo'        // https://paypal.com@evil.site
  | 'insecure'        // plain http
  | 'suspicious_tld'  // .zip, .mov, .top, .xyz…
  | 'impersonation'   // paypal-secure-login.com
  | 'many_subdomains'
  | 'malicious';      // remote verdict

A few of these are more interesting than they look.

The @ trick. In https://paypal.com@evil.site/, everything before @ is userinfo, so the real host is evil.site. I pull the host from the authority section and take what comes after the last @:

const authority = m[1];
const at = authority.lastIndexOf('@');
const hostPort = at >= 0 ? authority.slice(at + 1) : authority;

Brand impersonation. I look for a brand name anywhere in the host (with dots and dashes removed), unless the registrable domain belongs to that brand:

const owner = registrableLabel(host);          // "example" for a.b.example.co.uk
const flat = host.replace(/[-.]/g, '');
for (const [name, official] of Object.entries(BRANDS)) {
  if (flat.includes(name) && !official.includes(owner)) {
    reasons.push('impersonation');
    break;
  }
}

So paypal-secure.verify-account.xyz gets flagged, but www.paypal.com and paypal.co.uk pass. The brand list includes local targets too (Vietcombank, Techcombank, Shopee, Lazada), because phishing is regional.

Severity, not a yes/no answer. Some signals are near-certain red flags. Others are only "be careful":

const DANGER = ['userinfo', 'punycode', 'impersonation', 'ip_host'];
const level = reasons.some(r => DANGER.includes(r))
  ? 'danger'
  : reasons.some(r => r !== 'insecure' && r !== 'many_subdomains') || reasons.length >= 2
  ? 'caution'
  : 'safe';

A plain http:// link alone doesn't deserve a red banner. Crying wolf trains users to ignore warnings.

Then, optionally, ask Google

On top of the local result, the app can query Google Web Risk (uris:search) with a 5-second timeout. It's merged in only if it returns a verdict. If the device is offline or the request times out, the local result still stands:

export const withRemoteVerdict = (local: UrlRisk, malicious: boolean | null) =>
  malicious ? { ...local, level: 'danger', reasons: ['malicious', ...local.reasons] } : local;

2. Payment QRs: one parser, many countries

VietQR, PromptPay, PayNow, DuitNow, QRIS and Pix are all built on the EMVCo Merchant-Presented QR spec. The payload is a flat TLV string: 2-digit tag, 2-digit length, value. The parser fits in a few lines:

export const parseTlv = (s: string) => {
  const out: Record<string, string> = {};
  let i = 0;
  while (i < s.length) {
    if (i + 4 > s.length) return null;
    const tag = s.slice(i, i + 2);
    const len = Number(s.slice(i + 2, i + 4));
    if (!Number.isInteger(len) || i + 4 + len > s.length) return null;
    out[tag] = s.slice(i + 4, i + 4 + len);
    i += 4 + len;
  }
  return out;
};

Tag 54 is the amount, 59 the merchant name and 60 the city. Nested templates like 38 (VietQR) or 62 (additional data) are TLV strings themselves, so you just call parseTlv again.

Every EMVCo payload ends with 6304 plus a CRC-16/CCITT-FALSE checksum. Checking it costs almost nothing and catches damaged or edited codes:

export const crc16 = (s: string) => {
  let crc = 0xffff;
  for (let i = 0; i < s.length; i++) {
    crc ^= s.charCodeAt(i) << 8;
    for (let j = 0; j < 8; j++) {
      crc = crc & 0x8000 ? ((crc << 1) ^ 0x1021) & 0xffff : (crc << 1) & 0xffff;
    }
  }
  return crc.toString(16).toUpperCase().padStart(4, '0');
};

const crcValid = crc16(s.slice(0, -4)) === s.slice(-4).toUpperCase();

If the checksum fails, the user sees "QR may be damaged (checksum mismatch)". They're about to send money, so that warning matters. UPI, SEPA (EPC) and Swiss QR-bill use different formats. They get their own parsers, and IBANs are checked with mod-97.

3. When you generate codes, check them too

People love custom colors and a logo in the middle of their QR code, and then nobody can scan it. After rendering, ScanQR scans its own output and shows "Scannable — verified" or a warning. It also warns about low contrast, inverted colors and a logo that's too large.

Stack

React Native 0.81 (New Architecture), Reanimated 4
react-native-vision-camera + ML Kit barcode scanning
Open Food Facts / Open Beauty Facts / Open Library for product barcodes
i18next with 23 languages

Lessons

Do the work offline first. The local heuristics give an answer instantly, and the network check only adds to it.
Graded warnings beat yes/no. Too many red banners and users stop reading them.
Checksums are free safety. If a format has one (EMVCo CRC, IBAN mod-97), check it.

ScanQR is on App Store and Google Play. I'd love feedback, especially regional phishing patterns or payment formats I should add next. 🙏

I Got Tired of Losing Context Behind My Work Photos, So I Built FieldStamp

Nexa Tech — Fri, 17 Jul 2026 14:14:47 +0000

FieldStamp Link

Android: FieldStamp GPS Camera on Google Play

iPhone: FieldStamp GPS Camera on the App Store

A few months ago, I noticed something annoying about the photos on my phone.

I had a lot of them.

Photos from different places. Different days. Different projects. Some were taken just a few hours apart, so they looked almost the same.

At the time I took them, I knew exactly what each photo was for.

A few days later, I did not.

I would open my gallery and ask myself:

Was this taken at the first location or the second one?
What time did I take this?
Which project did this belong to?
Why did I take this photo again?

The photo was still there, but most of the useful context was gone.

That problem became the starting point for FieldStamp GPS Camera.

A Photo Is Not Always Enough

For personal photos, this is usually not a big issue.

You take a photo, keep it in your gallery, and maybe look at it again later.

But work photos are different.

People working in construction, maintenance, property inspections, agriculture, utilities, or field services often take photos as evidence.

The photo needs to show more than what the camera can see.

It may also need to answer:

Where was this taken?
When was it taken?
Which job or project was it related to?
What issue was being documented?
Can this photo be included in a report?

Without that information, someone usually has to remember it, write it down, rename the file, or organize everything manually later.

That sounds manageable when there are five photos.

It becomes painful when there are fifty.

My First Idea Was Very Simple

At first, I only wanted to add location and time directly to a photo.

Take a photo, display the GPS coordinates, address, date, and time on it, then save it.

Simple.

But while building the app, I realized that the watermark itself did not solve the full problem.

The next problem was organization.

Even if every photo had GPS information, users could still end up with hundreds of images mixed together.

So I added projects.

A user could create a project, select it before taking photos, and keep related photos in one place.

For example:

Apartment inspection
Construction Site A
Roof repair
Farm Area 2
Monthly equipment check

This made the app feel less like a normal camera and more like a small field documentation tool.

The Details That Became Important Later

While testing the app, I started noticing small things that I had not considered in the beginning.

GPS accuracy was one of them.

A phone may detect a location, but that does not always mean the location is accurate.

Sometimes the signal is good. Sometimes it is not.

So the app shows GPS accuracy before the photo is taken. The user can wait a little longer when an accurate location is important.

I also added information such as:

Coordinates
Address
Date and time
GPS accuracy
Altitude
Compass direction
Project name
Custom notes

Users do not need to display everything. They can choose a layout depending on what matters for their work.

Some people may only need the date and address.

Others may need coordinates, project information, and a note describing the issue.

The Photo Was Only Half of the Workflow

Another thing I learned was that taking the photo is often not the final step.

After a site visit or inspection, the photos may need to be sent to:

A manager
A client
A property owner
A contractor
A project team

Copying photos one by one into a document takes time, especially when each image also needs a description.

That is why I added PDF reports.

Users can select their field photos and create a report containing the images, project information, location details, and notes.

It is still a simple feature, but it removes a repetitive step from the workflow.

Instead of taking photos first and building the report somewhere else, both actions can happen in the same app.

What I Learned While Building It

The biggest lesson was that a feature is not the same as a complete workflow.

“Add GPS to a photo” is a feature.

But the real workflow is closer to this:

Arrive at a location.
Select the correct project.
Check the GPS signal.
Take several photos.
Add notes when needed.
Keep the photos organized.
Create a report.
Send it to someone else.

Thinking about the full workflow changed many of my product decisions.

I also learned that small utility apps need to be fast.

Someone standing outside at a job site does not want to go through six setup screens before taking a photo.

The app should open quickly, show the important information, and let the user continue working.

That sounds obvious, but it is easy to forget when you are building features from a desk.

FieldStamp Is Still a Work in Progress

FieldStamp is currently available on Android and iPhone.

Android:

FieldStamp GPS Camera on Google Play

iPhone:

FieldStamp GPS Camera on the App Store

I am still improving the camera experience, project organization, watermark layouts, and PDF reports.

I am also trying to understand how different people document their field work.

Some users care most about location accuracy.

Some care about report creation.

Others just want a quick way to prove when and where a photo was taken.

Building this app reminded me that many useful products start from a small, repetitive frustration.

For me, it was opening my photo gallery and realizing that I could no longer remember the story behind the photos.

That was the problem I wanted to fix.

From 0 to 1,000 Scans: The Journey of Building a React Native QR Scanner App

Nexa Tech — Thu, 16 Oct 2025 14:45:35 +0000

Hello, Dev Community!

Today, I want to share a story that’s about more than just writing code. It's about solving a problem, relentless learning, and finally, bringing an idea from a local machine to the hands of thousands of users. This is the journey of building ScanQR—my first major mobile application, now live on the Google Play Store.

This isn't just a "look what I made" post. This is a detailed map of how a modern, high-performance app is born, from the core business logic to the actual code snippets that make it all work.

📲 Download ScanQR for Free on Google Play and See It in Action!

Part 1: The Problem - Why Build Another QR Scanner?

The market is flooded with scanner apps, but I always felt something was missing. Most apps fell into one of these traps:

Slow and Ad-Ridden: The user experience was constantly interrupted.
Too Simple: They just scanned links, with no intelligent features.
Uninspired: Lacked any creative features, like a personalized QR code generator.

I wanted an all-in-one tool: lightning-fast, intelligent, secure, and one that empowers user creativity. That was the vision that led to ScanQR.

Part 2: The Heart of ScanQR - A Deep Dive into Core Features and Code

Let's dissect the features that make ScanQR stand out and look at the exact React Native code that brought them to life.

1. The High-Speed, Performance-Optimized Scanner Engine

This is the most critical feature. A slow scanner is a useless scanner.

The User Experience: Instantly scan codes, even in low light or when they're slightly damaged.
Inside the Code: I used react-native-vision-camera with its useCodeScanner hook. But I didn't just call the function; I heavily optimized it to prevent re-scans and reduce CPU load.

Here’s the core logic:

// ScanScreen.tsx

const lastValueRef = useRef<string>('');
const frameCountRef = useRef(0);
const debounceUntilRef = useRef(0);

const codeScanner = useCodeScanner({
  codeTypes: Platform.OS === 'ios' ? CODE_TYPES_IOS : CODE_TYPES_ANDROID,
  onCodeScanned: codes => {
    // Only process every Nth frame to save battery
    frameCountRef.current =
      (frameCountRef.current + 1) % SCAN_EVERY_NTH_FRAME;
    if (frameCountRef.current !== 0) return;

    // "Debounce" Logic: Block rapid, repetitive scans
    const now = Date.now();
    if (now < debounceUntilRef.current) return;

    const raw = codes[0]?.value?.trim();
    if (!raw) return;

    // If the code is identical to the last one, wait a bit
    if (raw === lastValueRef.current) {
      debounceUntilRef.current = now + 1000; // Wait 1 second
      return;
    }

    lastValueRef.current = raw;
    debounceUntilRef.current = now + 1200; // Set a cooldown for the new code

    // Parse and display the result
    const parsed = parseLink(raw);
    setResult(parsed);
    bottomSheetRef.current?.expand();
    haptic(); // Trigger haptic feedback
  },
});

Dev Analysis:

frameCountRef: A simple but effective trick to skip frames. This significantly reduces CPU usage and improves battery life.
debounceUntilRef & lastValueRef: This is a manual debouncing technique. It prevents the app from processing the same QR code dozens of times a second, which would cause the UI to stutter and create a jarring experience.

2. Smart, Context-Aware Actions

ScanQR doesn't just show you a string of text. It understands the content and suggests the appropriate action.

The User Experience: Scan a URL, get an "Open" button. Scan a phone number, get a "Call" button. Scan Wi-Fi credentials, get a "Copy Password" action.

Inside the Code: This logic lives in the primaryAction function. It's a large switch statement that operates on the result from my custom parseLink function.

Here's a snippet:

// ScanScreen.tsx

const primaryAction = async () => {
  if (!result) return;
  switch (result.kind) {
    case 'URL':
      await Linking.openURL(result.href);
      break;
    case 'PHONE':
      await Linking.openURL(`tel:${result.number}`);
      break;
    case 'EMAIL': {
      // ... logic to build email query params ...
      await Linking.openURL(`mailto:${result.to ?? ''}?${qp.toString()}`);
      break;
    }
    case 'WIFI':
      Clipboard.setString(
        `WIFI:T:${result.encryption};S:${result.ssid};P:${result.password};;`,
      );
      Toast.show({
        type: 'success',
        text1: t('message.copied_to_clipboard'),
      });
      break;
    // ... many more cases for vCard, SMS, Geo, Crypto ...
    default:
      if ('text' in result) {
        Clipboard.setString(result.text);
        Toast.show({ /* ... */ });
      }
      break;
  }
};

Dev Analysis: Separating the parsing logic (parseLink) from the action logic (primaryAction) keeps the code clean and maintainable. Using React Native's built-in Linking and Clipboard APIs allows for deep integration with the operating system.

3. Scan QR Codes from the Image Gallery

This is a convenient feature that many users requested.

The User Experience: Pick a photo containing a QR code from your gallery, and ScanQR will instantly recognize it.
Inside the Code: I combined two powerful libraries: react-native-image-crop-picker for selecting the image and @react-native-ml-kit/barcode-scanning for analyzing the static image.

The implementation is quite straightforward:

// ScanScreen.tsx
import ImageCropPicker from 'react-native-image-crop-picker';
import BarcodeScanning from '@react-native-ml-kit/barcode-scanning';

const onImagePicker = () => {
  ImageCropPicker.openPicker({ mediaType: 'photo' })
    .then(async image => {
      if (!image?.sourceURL && !image?.path) return;
      try {
        const uri = image.sourceURL ?? image.path;
        // Use ML Kit to scan the code from the image's URI
        const barcodes = await BarcodeScanning.scan(uri);
        const raw = barcodes?.[0]?.value?.trim();

        if (!raw) throw new Error('No barcode found');

        // Reuse the same parsing and display logic
        const parsed = parseLink(raw);
        setResult(parsed);
        bottomSheetRef.current?.expand();
        haptic();
      } catch {
        Toast.show({ type: 'error', text1: t('message.invalid_qr_code') });
      }
    })
    .catch(err => { console.log('Image picker error', err); });
};

Dev Analysis: The beauty here is reusability. Once I get the raw data from the image, I pass it through the exact same processing flow (parseLink, setResult, expand bottom sheet) as a camera scan. This is efficient and reduces code duplication.

Part 3: The Final Stretch - Publishing to the Google Play Store

Finishing the code is only half the battle. The publishing process is a whole other challenge:

Creating the App Bundle (.aab): Learning the process of signing and generating a production-ready build for Google Play.
Crafting the Store Presence: Designing an icon, taking screenshots, and writing compelling, SEO-friendly descriptions for the app page.
Privacy Policy: This is a must. I created a simple, clear privacy policy on GitHub Pages, committing to user privacy.
The Anxious Wait: Submitting the app and waiting for Google's review. The feeling of seeing that "Your app is now live" email is indescribable!

Conclusion and Your Invitation

The journey of building ScanQR has taught me so much about React Native, performance optimization, and the full product development lifecycle.

It was built with a developer's passion but designed for everyone. If you're looking for a powerful, privacy-respecting, and completely free QR code tool, please give ScanQR a try.

Download the App: Link

Put It to the Test: Scan everything, generate your own codes, and experience the difference.
Leave Feedback: Your reviews and suggestions are invaluable and will help shape the future of the app.

Thank you for reading my story. I hope it inspires anyone out there with a project idea of their own!

A question for my fellow devs: What was the biggest technical hurdle you've ever faced in a personal project? Share it in the comments below!

A Personal Guide to Setting Up React Native on Mac: My Journey

Nexa Tech — Sun, 12 Oct 2025 15:29:22 +0000

Hello, future teammate!

If you're reading this, I bet you're just as excited as I was to start building amazing mobile apps with React Native. It's an awesome choice! I've been exactly where you are now: thrilled, but also a little overwhelmed by the sheer number of tools you need to install.

This isn't another dry, technical document. This is my journal, my "lessons learned the hard way," shared with the hope of making your path a little smoother. Let's get started together!

Step 1: Gearing Up with the Right Tools

Just like a skilled carpenter needs a good set of chisels and a sturdy workbench, we need a solid foundation of software tools.

Homebrew - Your Ultimate Butler:

Think of Homebrew as your personal tech butler. Instead of hunting for download links on countless websites, you just type a command, and Homebrew fetches and installs everything for you. If you haven't met it yet, open your Terminal and summon it with this spell:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Official Docs: Homebrew Website

Node.js & Watchman - The Heart and the Pulse:

Node.js is the 'heart' that pumps life into your JavaScript code. It's the environment where everything runs.
Watchman is the 'pulse.' It's a little tool from Facebook that keeps an eye on your files. The moment you save a change, Watchman sees it and tells your app to reload instantly. This is the magic behind "Fast Refresh."

Let's get them both with our new butler, Homebrew:

brew install node
brew install watchman

Official Docs: Node.js & Watchman

Step 2: The iOS Adventure

To build apps for iPhones and iPads, we need to enter Apple's world. Xcode is the key.

1.Install Xcode: The best place to get this is the Mac App Store. A friendly warning: it's a huge file. This is a perfect time to go make a fresh cup of coffee (or two). It'll take a while.

Official Docs: Xcode on the Apple Developer Website

2.Set Up Command Line Tools: Once Xcode is installed, open it up. Go to Xcode > Settings > Locations. In the dropdown for "Command Line Tools," make sure a version is selected. This is like telling your Mac, "Hey, I've got all these cool new tools from Xcode, and you're allowed to use them from the Terminal."

3.CocoaPods - The Librarian:
Almost every iOS project uses extra bits of code from other developers, called libraries. CocoaPods is the friendly librarian that manages all of these for you. Let's install it:

sudo gem install cocoapods

Official Docs: CocoaPods Website

Step 3: The Android Quest

Android setup can feel like a side quest with a few more steps, but trust me, the feeling of seeing your app run on both platforms is worth it.

1.Java Development Kit (JDK) - The Lingua Franca:

Android's native language is Java/Kotlin, so we need a JDK to help React Native talk to it. Let's have Homebrew handle this for us:

brew install --cask zulu@17

After the JDK installation, add or update your JAVA_HOME environment variable in ~/.zshrc (or in ~/.bash_profile).

If you used above steps, JDK will likely be located at /Library/Java/JavaVirtualMachines/zulu-17.jdk/Contents/Home:

export JAVA_HOME=/Library/Java/JavaVirtualMachines/zulu-17.jdk/Contents/Home

2.Android Studio - The Command Center:
Download and install Android Studio from Google's website. During the setup, choose "Custom" installation and make sure these are checked:

Android SDK
Android SDK Platform
Android Virtual Device (this lets you create phone emulators)
Official Docs: Android Studio Website

3.Teaching Your Terminal the Way - Environment Variables:

This is the step where many people get stuck, but it's not as scary as it looks. We just need to leave a note for our Terminal telling it where to find all the Android tools.

Open your ~/.zshrc file (it's a hidden file in your home directory) and add these lines at the bottom:

export ANDROID_HOME=$HOME/Library/Android/sdk
export PATH=$PATH:$ANDROID_HOME/emulator
export PATH=$PATH:$ANDROID_HOME/platform-tools

After you save it, close and reopen your Terminal. This simple step makes sure that when you type a command like emulator, your computer knows exactly where to look.

Learn more: React Native Docs on Environment Variables

Step 4: The "It's Alive!" Magic Moment

Alright, the stage is set. It's time to bring your first creation to life.

1.Create Your Project:
In your Terminal, run this command. MyFirstApp can be whatever you want to name your project.

npx @react-native-community/cli@latest init MyFirstApp

2.Step Inside:

cd MyFirstApp

2.1.Run on IOS:
npm run ios
This will automatically boot up the iOS Simulator and you should see your app pop up. It's a magical feeling the first time!

2.2.Run on Android:

Run on Android:
First, open Android Studio and start an emulator from the AVD Manager. Then, in your terminal, run:
npm run android
And voilà! The same app, running on a completely different system.

Don't Panic! We've All Been There (Troubleshooting)

If you hit a roadblock, take a deep breath. Every single developer has faced these errors. You're not alone. Here are some common hurdles:

The Problem: pod install fails on your shiny new M1/M2/M3 Mac.
The Story: Your Mac's chip speaks a new language (ARM), but some old tools still speak the old one (x86). Sometimes they get lost in translation.
The Fix: Tell your Mac to use its built-in translator, Rosetta.

cd ios
arch -x86_64 pod install

The Problem: Android build complains it "can't find SDK location."
The Story: The message you left in ~/.zshrc got lost, or you forgot to restart the Terminal.
The Fix: Double-check the path in ~/.zshrc. If it's still not working, you can leave a more direct note inside the project. Create a file at android/local.properties and put this inside (remember to change YOUR_USERNAME!):

sdk.dir = /Users/YOUR_USERNAME/Library/Android/sdk

Your Journey Begins Now

And there you have it! You've successfully built your launchpad. The road ahead is filled with exciting challenges, learning, and the incredible joy of creating something from scratch. For your next steps, the official React Native documentation is your best friend.

Dive Deeper: React Native Official Documentation

Welcome to the club. Happy coding!

A Personal Guide to Setting Up React Native on Mac: My Journey

Nexa Tech — Sun, 12 Oct 2025 15:29:22 +0000

Hello, future teammate!

This isn't another dry, technical document. This is my journal, my "lessons learned the hard way," shared with the hope of making your path a little smoother. Let's get started together!

Step 1: Gearing Up with the Right Tools

Just like a skilled carpenter needs a good set of chisels and a sturdy workbench, we need a solid foundation of software tools.

Homebrew - Your Ultimate Butler:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Official Docs: Homebrew Website

Node.js & Watchman - The Heart and the Pulse:

Node.js is the 'heart' that pumps life into your JavaScript code. It's the environment where everything runs.
Watchman is the 'pulse.' It's a little tool from Facebook that keeps an eye on your files. The moment you save a change, Watchman sees it and tells your app to reload instantly. This is the magic behind "Fast Refresh."

Let's get them both with our new butler, Homebrew:

brew install node
brew install watchman

Official Docs: Node.js & Watchman

Step 2: The iOS Adventure

To build apps for iPhones and iPads, we need to enter Apple's world. Xcode is the key.

1.Install Xcode: The best place to get this is the Mac App Store. A friendly warning: it's a huge file. This is a perfect time to go make a fresh cup of coffee (or two). It'll take a while.

Official Docs: Xcode on the Apple Developer Website

sudo gem install cocoapods

Official Docs: CocoaPods Website

Step 3: The Android Quest

Android setup can feel like a side quest with a few more steps, but trust me, the feeling of seeing your app run on both platforms is worth it.

1.Java Development Kit (JDK) - The Lingua Franca:
Android's native language is Java/Kotlin, so we need a JDK to help React Native talk to it. Let's have Homebrew handle this for us:

brew install --cask zulu@17

After the JDK installation, add or update your JAVA_HOME environment variable in ~/.zshrc (or in ~/.bash_profile).

If you used above steps, JDK will likely be located at /Library/Java/JavaVirtualMachines/zulu-17.jdk/Contents/Home:

export JAVA_HOME=/Library/Java/JavaVirtualMachines/zulu-17.jdk/Contents/Home

2.Android Studio - The Command Center:
Download and install Android Studio from Google's website. During the setup, choose "Custom" installation and make sure these are checked:

Android SDK
Android SDK Platform
Android Virtual Device (this lets you create phone emulators)
Official Docs: Android Studio Website

3.Teaching Your Terminal the Way - Environment Variables: **
This is the step where many people get stuck, but it's not as scary as it looks. We just need to leave a note for our Terminal telling it where to find all the Android tools.
Open your **~/.zshrc file (it's a hidden file in your home directory) and add these lines at the bottom:

export ANDROID_HOME=$HOME/Library/Android/sdk
export PATH=$PATH:$ANDROID_HOME/emulator
export PATH=$PATH:$ANDROID_HOME/platform-tools

After you save it, close and reopen your Terminal. This simple step makes sure that when you type a command like emulator, your computer knows exactly where to look.

Learn more: React Native Docs on Environment Variables

Step 4: The "It's Alive!" Magic Moment

Alright, the stage is set. It's time to bring your first creation to life.

1.Create Your Project:
In your Terminal, run this command. MyFirstApp can be whatever you want to name your project.

npx @react-native-community/cli@latest init MyFirstApp

2.Step Inside:

cd MyFirstApp

2.1.Run on IOS:
npm run ios
This will automatically boot up the iOS Simulator and you should see your app pop up. It's a magical feeling the first time!

2.2*Run on Android:*
Run on Android:
First, open Android Studio and start an emulator from the AVD Manager. Then, in your terminal, run:
npm run android
And voilà! The same app, running on a completely different system.

Don't Panic! We've All Been There (Troubleshooting)

If you hit a roadblock, take a deep breath. Every single developer has faced these errors. You're not alone. Here are some common hurdles:

The Problem: pod install fails on your shiny new M1/M2/M3 Mac.
The Story: Your Mac's chip speaks a new language (ARM), but some old tools still speak the old one (x86). Sometimes they get lost in translation.
The Fix: Tell your Mac to use its built-in translator, Rosetta.

cd ios
arch -x86_64 pod install

The Problem: Android build complains it "can't find SDK location."
The Story: The message you left in ~/.zshrc got lost, or you forgot to restart the Terminal.
The Fix: Double-check the path in ~/.zshrc. If it's still not working, you can leave a more direct note inside the project. Create a file at android/local.properties and put this inside (remember to change YOUR_USERNAME!):

sdk.dir = /Users/YOUR_USERNAME/Library/Android/sdk

Your Journey Begins Now

Dive Deeper: React Native Official Documentation

Welcome to the club. Happy coding!