DEV Community: Abdelhakim mohamed

Why I Built My Own IAP System Instead of Using RevenueCat

Abdelhakim mohamed — Sat, 01 Aug 2026 16:06:39 +0000

Apple takes 15%. RevenueCat takes another 1% of tracked revenue on top.

That's one dollar in six, and the last slice goes to a service that forwards JSON between my server and Apple's.

So I built it myself for Nutix over a weekend, both platforms. Claude Code one-shot most of the implementation — and that's the point. The code isn't the hard part anymore. The edge cases are, and they're what took the rest of the weekend.

This post is those edge cases.

For react-native-iap I found this post most useful for me React Native IAP

Should you?

Use RevenueCat if you're pre-revenue, or you don't want payments to be something you're on call for. At low revenue the 1% is rounding error and you get a real dashboard for free.

Build it yourself if the fee is a real line item, or you want payments to be something you understand rather than something you configure.

The usual argument for RevenueCat is cross-platform — one entitlement model across StoreKit and Google Play. I did both myself. It's genuinely more work, but it's a weekend of work, not a quarter.

Everything below is the Apple side, for simplicity.

1. The client decides nothing

StoreKit 2 hands you a JWS. The app forwards it and waits. It never decodes it, never checks expiresDate, never unlocks anything locally.

RNIap.purchaseUpdatedListener(async (purchase) => {
  // StoreKit replays old transactions on every launch. Not user intent.
  if (!pendingPurchaseRef.current && !pendingRedemptionRef.current) {
    await RNIap.finishTransaction({ purchase, isConsumable: false });
    return;
  }

  await subscriptionService.verifyReceipt({
    transactionId: purchase.transactionId!,
    receiptData: purchase.purchaseToken,
  });

  // Finish AFTER the server has it. Non-fatal if it throws.
  try {
    await RNIap.finishTransaction({ purchase, isConsumable: false });
  } catch (e) {
    logIAPError('finishTransactionFailed', e);
  }
});

Three rules:

Finish after your server records the purchase. Do it before, and a crash between the two leaves a paying user with nothing.
Guard against replays. Without that check, my success screen fired on app launch for people who bought weeks ago.
Don't await requestPurchase. It doesn't resolve when the user dismisses the sheet. Resolve from the listener pair instead. If you're awaiting it today, you have a hung spinner in production.

2. Ask Apple, don't trust the receipt

Decode the token for originalTransactionId and environment. Then call the App Store Server API for the real state.

Gotchas: your auth JWT can't live longer than 60 minutes, and sandbox is on a different host — which you only know after decoding.

Where mine is wrong: Apple's payloads carry a certificate chain you're meant to verify up to their root CA. I don't. I decode and lean on TLS. For the API path that's defensible. For the webhook path it isn't — anything that can POST to my endpoint gets parsed. Use app-store-server-library-node and skip my mistake.

3. Key on `originalTransactionId`

It's Apple's stable ID for the whole subscription lifetime — it survives renewals, plan changes, resubscribes. transactionId changes every renewal and is useless as a key.

Your table is a cache. Apple is the truth.

4. Most of the work happens while the app is closed

Renewals at 3am. Billing retries. Cancellations from Settings. Refunds. None of it produces a client call — you need App Store Server Notifications V2.

Two subtypes cost money if you get them wrong:

case 'DID_CHANGE_RENEWAL_STATUS':
  // Cancelling a PAID period doesn't end access. Apple sends EXPIRED later.
  if (subtype === 'AUTO_RENEW_DISABLED' && subscription.isTrialPeriod) {
    subscription.status = 'cancelled';
  }
  break;

case 'DID_FAIL_TO_RENEW':
  // GRACE_PERIOD means keep them premium.
  subscription.status = subtype === 'GRACE_PERIOD' ? 'grace_period' : 'billing_retry';
  break;

Someone who cancels on day 3 of a paid month keeps premium until day 30. Revoke early and you've stolen 27 days.

Handlers must be idempotent, and return 200 fast — Apple retries on anything else.

5. Signing promotional offers

The one section Apple documents completely and uselessly, and the one place the generated code was confidently wrong. Get it wrong and StoreKit fails with a generic error and no hint which field was bad.

const SEP = '\u2063';  // INVISIBLE SEPARATOR. Write the escape, never the character.
const payload = [
  bundleId,
  keyId,               // In-App Purchase key, NOT the Server API key
  productId,
  offerIdentifier,
  applicationUsername, // '' if unused — the empty slot still counts
  crypto.randomUUID(),
  String(Date.now()),  // MILLISECONDS
].join(SEP);

const signature = crypto
  .sign('SHA256', Buffer.from(payload), {
    key: crypto.createPrivateKey({ key: pem, format: 'pem' }),
    dsaEncoding: 'ieee-p1363', // Node defaults to DER. Apple wants raw r||s.
  })
  .toString('base64');

All four comments are things that failed silently on me. The separator is the worst — it's zero-width, so it won't survive a copy-paste out of rendered docs. That's why half the posts about this are wrong, and probably why the models trained on them are too.

Introductory offers need none of this. Apple handles eligibility; you just read offerType: 1.

What broke

Sandbox testing is miserable. A month renews in five minutes, accounts get stuck in states you can't clear, and notifications sometimes just don't arrive — so you can't tell a broken handler from a missing event. Budget as much time for testing as for the code.

That's the real shape of this project now. Generating the implementation is an afternoon. Knowing which of the generated lines will quietly cost you money is the weekend.

The 1% was the excuse. Wanting to know what happens between a tap and a row in my database was the reason.

How I Built a Multilingual Food Database Using a Local LLM on an AMD GPU

Abdelhakim mohamed — Thu, 22 Jan 2026 23:14:09 +0000

Two weeks ago, I launched my first app Nutix Ai, a calorie tracking app focused on simplicity. It's now at 200 downloads, which feels great for a first launch.

Today I want to share one specific part of the journey: building a food database that supports multiple languages (English, Arabic, Spanish) — not just English like most nutrition apps.

Why Multilingual?

Most calorie tracking apps have English-only databases, or their translations feel like afterthoughts. I wanted native speakers to actually be able to search for foods in their language from day one.

The Architecture

Simple setup:

Local LLM running on my AMD 9070XT (yes, not NVIDIA — and it worked great)
Base food data in English
LLM translates each entry to Arabic and Spanish
Output stored in my database

The Model Hunt (The Painful Part)

Finding the right model took longer than I expected.

Model	Speed	Translation Quality (especially Arabic)
DeepSeek 7B	Slow	Terrible
DeepSeek 8B	Slow	Terrible
DeepSeek 14B	Very slow	Still bad
Llama variants	Moderate	Poor
QWEN	Had high hopes	Performed worse than expected
Gemma3 7B	~200 tok/s	Good (1-5% error rate)
Gemma3 12B	~80 tok/s	Great

Gemma3 was the winner. The 7B was fast but had occasional errors. The 12B took about 2 seconds per food item but was much more reliable.

The Result

~6,000 foods translated into 3 languages in 4 hours, all generated locally on consumer hardware.

Known Issues & What's Next

Database size — 6K foods is a start, but I want to expand to 12+ languages and more regional foods
Search — The food search still needs work. Fuzzy matching across multiple languages is tricky

Looking for Suggestions

If you have ideas for:

Good sources of food/nutrition data
Improving multilingual search
Other languages I should prioritize

Drop them in the comments — I'd genuinely appreciate it.

You can check out the app here: Nutix on the App Store

Built a nutrition app with React Native + Expo SDK 54 that actually feels native on iOS 👀

Abdelhakim mohamed — Thu, 04 Dec 2025 01:34:03 +0000

Opening beta to the first 1000 users for free
Would love your feedback — what feels off? What could be better?
https://testflight.apple.com/join/ZVUxTEAt

DDoS Protection: How to Monitor, Detect, and Defend Against Attacks

Abdelhakim mohamed — Sat, 07 Jun 2025 01:09:13 +0000

The Midnight Server Meltdown: What To Do When Your Backend Goes Silent

Imagine this: it’s a peaceful night, maybe you’re winding down, enjoying a movie, or catching up on some sleep. Suddenly, your phone rings it's your client or your boss. Their voice is urgent:

“The server is down. Customers can’t access anything. Everything’s super slow!”

Your heart races. You scramble to your desk, half awake but fully alert now. You SSH into the server or open your monitoring dashboard nothing seems obviously broken. You check the logs they’re there, but not helpful. You hit a few endpoints they respond… eventually. What used to take 200ms is now crawling at 10 seconds or, even worse, timing out.

At this point, panic is knocking on your door.

You start digging deeper. CPU usage is spiking, memory is being eaten up, and your server is getting hammered with requests. But they aren’t normal requests they’re overwhelming, coming from a swarm of IPs. That’s when it hits you:

You're under a DDoS attack. Someone, somewhere, decided to bring your server to its knees.

Now the real question is what do you do to prevent this from happening again?

Set Up Rate Limiting
Limit how many requests each IP can make per second using Nginx. This helps slow down bots and flood attempts before they hurt your server.

If your using Nginx consider adding this inside nginx.conf

http {
  limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

  server {
    listen 80;

    location /api/ {
      limit_req zone=mylimit burst=20 nodelay;
    }
  }
}

10r/s Limits each IP address to a maximum of 10 requests per second.
zone=mylimit:10m Creates a shared memory zone named mylimit that can track up to approximately 160,000 unique IP addresses with 10MB of memory.
burst=20 Allows short traffic spikes by permitting up to 20 excess requests to queue temporarily before triggering rate limiting.

Monitor Abusive IPs
Keep an eye on which IPs are getting rate-limited. If the same ones show up repeatedly, it’s a red flag something is trying to break in or overwhelm your system.

Add the following to your nginx.conf to enable logging:
This ensures that NGINX logs blocked or rate-limited requests along with the client’s IP address.

http {
  limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;
  log_format rate_limited '$remote_addr - $request - $status - $http_user_agent';

  map $status $log_rate_limit {
    503     1;
    default 0;
  }

  access_log /var/log/nginx/ratelimited.log rate_limited if=$log_rate_limit;

  server {
    listen 80;

    location /api/ {
      limit_req zone=mylimit burst=20 nodelay;
    }
  }
}

Automatically Ban Suspicious IPs
Use tools like fail2ban to detect patterns of abuse and block the source IP for a set period. This adds another layer of defense beyond just rate limiting.

sudo apt update
sudo apt install fail2ban

/etc/fail2ban/jail.conf: Default config
/etc/fail2ban/jail.d/: Your custom jail files
/etc/fail2ban/filter.d/: Contains filters

Let’s say we want to block any IP that gets rate-limited too often (503 status in your Nginx log).

1. Create a custom jail

/etc/fail2ban/jail.d/nginx-limit.conf

[nginx-limit]
enabled  = true
port     = http,https
filter   = nginx-limit
logpath  = /var/log/nginx/ratelimited.log
maxretry = 10
findtime = 60
bantime  = 600

Ban IPs that match the filter 10 times in 60 seconds
Ban them for 10 minutes

2. Create the filter file

/etc/fail2ban/filter.d/nginx-limit.conf

[Definition]
failregex = ^<HOST> - .+ - 503 - .*

This regex matches lines like:

192.168.1.5 - /api/endpoint - 503 - curl/7.58.0

It extracts the <HOST> (IP address) and counts the hits.

Start or Restart Fail2Ban

sudo systemctl restart fail2ban

Check Status and Banned IPs

sudo fail2ban-client status

Check specific jail:

sudo fail2ban-client status nginx-limit

Unban a specific IP (if needed):

sudo fail2ban-client set nginx-limit unbanip 192.168.1.5

Use reCAPTCHA to Stop Bots Cold
Especially for sensitive actions like login or guest access, adding Google reCAPTCHA can stop automated scripts in their tracks, without bothering real users much.

Thanks for reading my article 🙌

Understanding Express Routes, Controllers, and Services

Abdelhakim mohamed — Sat, 28 Sep 2024 21:51:42 +0000

Introduction

If you're new to Express.js or Node.js, you might have heard about "routes," "controllers," and "services." At first, these terms sound technical, but trust me understanding them can really transform how you build your apps. Not only will your code look cleaner, but it'll also make your life easier as your app grows. In this guide, we'll break down what each of these components does and why separating them is a game-changer for any Express project.

Let's start by setting up a basic Express app and organizing everything like a pro!

Setting Up Your Project

First things first let’s create a new Node.js project. Fire up your terminal and follow these steps:

Initialize your project by running:

   npm init -y

Install Express to get the magic going:

   npm install express

Now, let’s structure our project to keep things clean. Here’s how your folder setup should look:

my-express-app
│
├── src
│   ├── controllers
│   ├── routes
│   ├── services
│
├── app.js
└── package.json

We'll walk through what goes into each of these folders. Don't worry if this looks like a lot; it's easier than it seems!.

Routes: The Traffic Cops of Your App

Think of routes as traffic cops—they decide where each request should go. They don’t do much heavy lifting themselves but delegate the real work to controllers.

Here’s how you can create a basic route for user-related requests:

// src/routes/userRoutes.js
const express = require('express');
const router = express.Router();
const userController = require('../controllers/userController');

// Define routes
router.get('/users', userController.getAllUsers);
router.post('/users', userController.createUser);

module.exports = router;

In this example, when someone hits /users with a GET request, our app calls the getAllUsers function from the controller. Pretty neat, right?

Controllers: The Brains of the Operation

Now, controllers are where the logic happens. They take what the routes send their way and handle all the complex stuff like fetching data or saving a new user.

Let’s build a simple controller:

// src/controllers/userController.js
const userService = require('../services/userService');

exports.getAllUsers = (req, res) => {
  const users = userService.fetchUsers();
  res.status(200).json(users);
};

exports.createUser = (req, res) => {
  const newUser = userService.addUser(req.body);
  res.status(201).json(newUser);
};

Here, the controller is getting data from a service (which we'll talk about next) and sending a response back. Think of the controller as the middleman between routes and services—it doesn't handle data directly but knows who to ask.

Services: The Real Workers

Services handle the real business logic, like interacting with a database or managing data. This keeps your controllers nice and clean.

Check out this basic service that manages a list of users:

// src/services/userService.js
const users = [];

exports.fetchUsers = () => {
  return users;
};

exports.addUser = (user) => {
  users.push(user);
  return user;
};

Here, we’re storing users in an array (for simplicity). Services help keep your controllers lightweight and focused on handling requests instead of worrying about the data itself.

Bringing It All Together in `app.js`

Once you have your routes, controllers, and services set up, you need to wire everything together in your main application file (app.js):

// app.js
const express = require('express');
const app = express();
const userRoutes = require('./src/routes/userRoutes');

app.use(express.json());
app.use('/api', userRoutes);

const PORT = process.env.PORT || 3000;
app.listen(PORT, () => {
  console.log(`Server running on port ${PORT}`);
});

In this file, we tell Express to use our userRoutes for any requests that start with /api. This makes it easy to organize all your routes under one common base path.

How Your Final Directory Should Look

Once you've set up everything, your directory structure should look something like this:

my-express-app
│
├── src
│   ├── controllers
│   │   └── userController.js
│   ├── routes
│   │   └── userRoutes.js
│   ├── services
│   │   └── userService.js
│
├── app.js
└── package.json

Wrapping Up

By splitting your app into routes, controllers, and services, you've just taken the first step towards writing better, cleaner code! Not only does this make your project easier to manage now, but it also saves you headaches as your app gets more complex. Plus, your future self (and your teammates) will thank you!

Happy Coding😊