DEV Community: hiro@

Release process for continuously delivering a personal dev app to TestFlight

hiro@ — Sun, 16 Aug 2026 00:30:23 +0000

This article is an English translation of the original Japanese article.

In personal development, you cannot always ship the next build while the release procedure is still fresh. If weeks pass, you end up researching the difference between version and build number, certificates, and the boundary with EAS Update again.

SquadNote uses EAS Build and EAS Submit, separating changes that require store submission from changes deliverable via OTA.

Separate version and build number

Expo config holds the user-visible version:

export default {
  version: "1.0.11",
  ios: {
    bundleIdentifier: "com.squadnote.app",
    buildNumber: "2",
  },
};

On the EAS side, appVersionSource is remote, and production build has autoIncrement: true.

{
  "cli": {
    "appVersionSource": "remote"
  },
  "build": {
    "production": {
      "autoIncrement": true,
      "channel": "production"
    }
  }
}

When recreating a TestFlight build with the same version, build number cannot duplicate. Delegating to automatic numbering reduces number corrections right before submission.

Determine change type before release

If only JavaScript and images changed, you can use EAS Update. If you changed native libraries, Expo SDK, plugins, or iOS settings, you need a new build.

When shipping a new binary, decide the version and check:

expo install --check and expo-doctor
TypeScript and tests
Production API URL
Expo config such as Universal Links or permission strings
Login, notifications, main screens on device

production build and submit

Run the build from the mobile package:

cd apps/mobile
eas build --platform ios --profile production

Send the completed build to TestFlight:

eas submit --platform ios --profile production --latest

The submit profile in eas.json has App Store Connect App ID and Team ID. Credentials themselves are not in the repository.

What to verify in TestFlight

Even if a development build works, some features can only be verified with production signing and production domain. I verify Universal Links, Sign in with Apple, and push notifications in the TestFlight build.

After verification, minor JS fixes to the same version can be delivered OTA to the production channel. When native changes enter, move to the next version.

Leave procedure in commits

At release time, I make the version update an independent commit. This makes it easier to trace which code was submitted to TestFlight from Git history.

What helped most for continuous delivery was fixing decision criteria rather than the amount of automation. If you have decided whether OTA is acceptable, whether a binary is needed, and what to verify in TestFlight, you can return to the procedure even after a long gap.

References

Why Waitlist Promotion Should Be Determined Server-Side, Not Client-Side

hiro@ — Sat, 15 Aug 2026 00:29:10 +0000

This article is an English translation of the original Japanese article.

In an attendance system with capacity limits, I was initially classifying participants and waitlist entries on the client side. At first, I simply sorted responses by createdAt and treated anything beyond capacity as waitlisted. Once I added proxy entry and guest participation, different screens started showing inconsistent results.

Now the waitlist logic is centralized on the server, and the API returns isWaitlisted.

`createdAt` does not reflect participation order

Creating a response record early doesn't mean the person chose to attend from the start. Someone who initially responded "not attending" and later changed to "attending" would jump to the front of the waitlist if sorted by createdAt.

To fix this, I save the timestamp when status changed to attending as attendingSince.

export function nextAttendingSince(
  previousStatus: string | null,
  newStatus: string,
  previous: Date | null,
  now: Date,
): Date | null {
  if (newStatus !== "attending") return null;
  if (previousStatus === "attending") return previous ?? now;
  return now;
}

Updating only the comment preserves the position. Canceling and re-attending sends the person to the back of the queue at that moment.

Merge members and guests into a single queue

Capacity applies to the combined total of members and guests. Calculating them separately could show both groups as within capacity.

const queue = [
  ...members
    .filter((item) => item.status === "attending")
    .map((item) => ({ kind: "member", id: item.id, at: joinedAt(item) })),
  ...guests
    .filter((item) => item.status === "attending")
    .map((item) => ({ kind: "guest", id: item.id, at: item.createdAt })),
].sort((a, b) => a.at - b.at || a.id.localeCompare(b.id));

const waitlisted = queue.slice(capacity);

When timestamps are equal, use the ID as a secondary key. This ensures the same data produces the same order in every request.

Find promotions by comparing before and after

Compute the waitlist before and after operations like cancellations, proxy entries, guest deletions, or capacity changes.

const before = computeWaitlist(capacityBefore, membersBefore, guestsBefore);

await updateAttendance();

const after = computeWaitlist(capacityAfter, membersAfter, guestsAfter);
const promotedIds = promotedMemberIds(before, after, membersAfter);

Notify only members who were waitlisted before and within capacity after. Computing this diff on the client misses operations by other users or administrators.

Use API response for display

The list API attaches isWaitlisted to each record.

return rows.map((row) => ({
  ...row,
  isWaitlisted: waitlist.waitlistedMemberIds.has(row.id),
}));

Web and mobile clients just display this value. Not duplicating capacity logic across screens avoids inconsistencies like badges differing between the admin panel and user view.

In production, strict handling of concurrent updates would require database transactions or serialization. This fix first eliminated the state where multiple clients each guessed the waitlist using different rules. Waitlist order and promotion notifications are business rules, so having the server return a single result makes them easier to manage.

Design evolution toward using the same auth and permission model in Next.js and Expo

hiro@ — Fri, 14 Aug 2026 00:52:20 +0000

This article is an English translation of the original Japanese article.

I added an Expo app to a Next.js service that was running on NextAuth. Web uses cookies, mobile uses Bearer JWT. Authentication methods differ, but the session format and permission checks after entering the API are shared.

It did not start in this form. I went through a structure where mobile directly handled Google auth, then a structure using web auth from an in-app browser, before settling on the current boundary.

Web kept NextAuth cookies

Existing web uses NextAuth sessions. Replacing this just to add mobile would affect login, account linking, and existing sessions.

So I kept web as is and added a JWT entry point just for mobile.

Web     -> Cookie -> tRPC context
Mobile  -> Bearer JWT -> tRPC context
                        -> same session.user

Mobile goes through web OAuth

From Expo, I use openAuthSessionAsync to open web authentication. After OAuth completes, the server goes through a short auth flow to return an app JWT, and the app stores it in SecureStore.

const result = await WebBrowser.openAuthSessionAsync(loginUrl, redirectUrl);

API requests put it in the Authorization header.

async headers() {
  const token = await getToken();
  return token ? { authorization: `Bearer ${token}` } : {};
}

Align to the same user format in tRPC context

The server checks cookie session first, then verifies Bearer JWT if absent.

const session = await auth();

if (!session?.user) {
  const header = opts.headers.get("authorization");
  if (header?.startsWith("Bearer ")) {
    const result = await verifyJwt(header.slice(7), secret);
    // Read user from DB, shape to match session.user
  }
}

JWT contains only user ID. name, email, image are fetched from the DB and shaped to match web session.user. This way, code that uses user name in notifications does not need to care about access origin.

Separate authentication and authorization

Whether logged in is checked in protectedProcedure. Operational permissions within organizations are judged by separate authorization helpers.

await assertMember(ctx, organizationId);
await assertAdminOrOwner(ctx, organizationId);

Even if a mobile screen hides a button, API checks are not skipped. Screen permission display is for usability, server authorization is for data protection.

401 is handled once on mobile side

When JWT expires, parallel requests may all return 401 at once. If each query handles logout individually, navigation overlaps.

let isHandlingUnauthorized = false;

async function handleUnauthorized() {
  if (isHandlingUnauthorized) return;
  isHandlingUnauthorized = true;
  await clearAuth();
  router.replace("/login");
}

Rather than fully sharing authentication methods, I shared everything after API context. Web and mobile differ in how they hold credentials. On the other hand, the permission model after obtaining user ID is the same. With this boundary, I could add mobile while keeping existing web.

Switching Between Web URLs and App Deep Links for LINE In-App Browser

hiro@ — Thu, 13 Aug 2026 00:23:26 +0000

This article is an English translation of the original Japanese article.

When sharing schedules or invite links via LINE, the link opens in the LINE in-app browser. For public pages that only require viewing, this is not a problem. However, for pages requiring Google login, authentication may fail.

As a countermeasure, I unified the entry point to HTTPS URLs and made the web side determine whether guidance to an external browser is needed.

Not Directly Sharing Custom Scheme

The app has a custom scheme.

squadnote://invite/org_123

However, this URL has no destination when the app is not installed. For URLs shared to LINE, I use HTTPS, which can also be opened on the web.

https://squad-note.com/invite/org_123?openExternalBrowser=1

On iOS, Universal Links are configured, so if the app is installed, the same HTTPS URL can open the app. For devices without the app, it displays the web page.

Separating Public and Member Pages

For schedule sharing, I change the path based on the public setting.

const path = schedule.isPublic
  ? `/s/${orgId}/${scheduleId}`
  : `/organizations/${orgId}/schedules/${scheduleId}`;

const url = `${config.apiUrl}${path}?openExternalBrowser=1`;

If it is a public schedule, I share /s/..., which does not require login. For non-public schedules, I use the member path. Sending everything to the login screen makes it unclear whether the recipient can view the content.

The Parameter Is Not for Opening the App

openExternalBrowser=1 is not a setting to enable Universal Links. It is a signal for the web to display guidance to move to an external browser when opened in the LINE in-app browser.

Separating the roles:

HTTPS URL: common entry point for sharing
Universal Links: association with installed app
Web public page: fallback for users without the app
openExternalBrowser=1: workaround for authentication in LINE in-app browser

Adding the query parameter alone does not make LINE automatically open Safari or Chrome. On the web side, I check the User-Agent and query parameter, then display instructions to open in an external browser.

Separating Share Message from URL

On the React Native side, I used the OS share sheet.

const name = schedule.title ?? schedule.location ?? "Practice";
const message = `${name} ${date} ${startTime}-${endTime}\n${url}`;

await Share.share({ message });

I do not restore the destination from the share message, but instead include the necessary ID in the URL itself. Since both the app side and the web side can interpret the same path, I did not need to add branching for each sharing destination in React Native.

LINE workarounds and deep links appear similar, but they are issues on different layers. By consolidating shared URLs to HTTPS and keeping app association and web browser workarounds independent, the structure becomes easier to maintain.

References

Data design for attendance management with capacity, waitlist, and proxy input

hiro@ — Wed, 12 Aug 2026 00:51:17 +0000

This article is an English translation of the original Japanese article.

A simple attendance sheet can be built with three things: user, schedule, and participation state. When you add capacity, waitlist, guests, and admin proxy input, a single "attending" value can no longer represent the state.

In SquadNote, I separated response state from waitlist position. Waitlist is not an independent response value, but a result of dividing people who expressed attendance by capacity.

Core columns in attendance

Member attendance has this information:

type Attendance = {
  id: string;
  scheduleId: string;
  userId: string;
  status: "attending" | "absent" | "maybe";
  comment: string | null;
  attendingSince: Date | null;
  updatedByAdmin: boolean;
  createdAt: Date;
  updatedAt: Date;
};

I did not add waitlisted to status because capacity changes or other participants' cancellations automatically move people inside capacity. The user's own response remains attending, and the current waitlist state is computed.

attendingSince separate from createdAt

The time a response was created differs from the time attendance was expressed. If someone who initially responded absent later changes to attending, they are placed in the waitlist at the time of change.

if (newStatus !== "attending") return null;
if (previousStatus === "attending") return previousAttendingSince ?? now;
return now;

Comment edits preserve the value, and once attendance is cancelled, it resets to null. On re-attendance, a new timestamp is set.

Guests consume the same capacity

Guests do not have accounts; admins enter their names as proxy input. They are in a separate table from members, but capacity calculation joins them into one list.

const queue = [...memberEntries, ...guestEntries]
  .sort((a, b) => a.at - b.at || a.id.localeCompare(b.id));

const insideCapacity = queue.slice(0, capacity);
const waitlisted = queue.slice(capacity);

In the current design, guests lack attendingSince, so I use createdAt. The important point is not calculating capacity separately for members and guests.

Record proxy input history

Because admins can change other members' responses, I have updatedByAdmin. This distinguishes admin-changed responses from self-changed ones, useful for screen display and inquiry verification.

Even for proxy input, waitlist rules are the same. When an admin changes to attending, attendingSince is set at that moment; when removing attendance, promoted members are calculated.

Capacity changes are treated as the same event as attendance changes

If capacity increases from 10 to 11, the top waitlisted person is promoted. If only cancellations trigger notifications, this path is missed.

Processing creates waitlists with before and after capacity, then takes the difference.

const before = computeWaitlist(oldCapacity, members, guests);
const after = computeWaitlist(newCapacity, members, guests);
const promoted = promotedMemberIds(before, after, members);

Display waitlist state is returned by the API. I do not duplicate the same calculation in web and mobile.

This design recalculates the waitlist every time. If participant count grows large, persisting rank or serializing updates become considerations. At the current scale, I prioritized being able to reproduce from source data and keeping rules in one place.

Supporting Language Switching for Date Formats, Not Just Text, with i18next

hiro@ — Tue, 11 Aug 2026 00:02:58 +0000

This article is an English translation of the original Japanese article.

After introducing i18next to a React Native app, dates like 7月24日(金) remained in Japanese on the screen. Just adding more translation JSON does not change places where Date is directly formatted.

To avoid having text and dates in different languages, I unified the language detection and passed it to Intl.DateTimeFormat.

Three Language Settings

The setting values are Japanese, English, and follow device, for a total of three types.

export type LanguagePreference = "system" | "ja" | "en";

I save the user's choice in SecureStore. Only when system, I read the device locale from Hermes's Intl.

function detectSystemLanguage(): "ja" | "en" {
  const locale = Intl.DateTimeFormat().resolvedOptions().locale;
  return locale.toLowerCase().startsWith("ja") ? "ja" : "en";
}

In this implementation, I also call i18n.changeLanguage the moment the UI changes.

export async function setLanguagePreference(pref: LanguagePreference) {
  await SecureStore.setItemAsync(LANGUAGE_KEY, pref);
  const language = pref === "system" ? detectSystemLanguage() : pref;
  await i18n.changeLanguage(language);
}

Not Handwriting Dates

Previously, I held months and weekdays in arrays and assembled strings. I replace this with Intl.DateTimeFormat.

export function formatScheduleDate(value: Date, language: string) {
  const locale = language === "ja" ? "ja-JP" : "en-US";

  return new Intl.DateTimeFormat(locale, {
    month: "long",
    day: "numeric",
    weekday: "short",
  }).format(value);
}

In components, I use i18n.resolvedLanguage.

const { t, i18n } = useTranslation();
const label = formatScheduleDate(date, i18n.resolvedLanguage ?? "ja");

I check resolvedLanguage to align with the language i18next actually adopted, including fallbacks.

Gradually Increasing Translation Coverage

Replacing all screens at once means tracking translation gaps and layout breaks simultaneously. I actually proceeded in the following order:

Language saving, dashboard, and tabs
Main screens for attendance registration
Settings, notifications, admin screens, and date displays

By handling date support last, I could verify it separately from text translation gaps. I check if the weekday changed, if the month-day order changed, and if the layout breaks with long English representations.

Counting only strings passing through the translation function does not determine the completion of multi-language support. Displays generated outside JSON, like dates, times, numbers, and error messages, also need to connect to the language setting.

References

The Stale Godot Class Cache Bug That Passed CI but Broke Local Startup

hiro@ — Mon, 10 Aug 2026 03:36:12 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project overview

Nocturne Vania is a small pixel-art Metroidvania built with Godot 4. The game has interconnected rooms, enemy AI, save data, unlockable movement abilities, and a growing automated test suite.

I hit this bug after adding a bell tower area. The new rooms, enemies, effects, and map markers used GDScript's class_name keyword so they could be referenced as global types.

The new area worked in a freshly imported project and in CI. It did not always work in an existing local checkout.

Bug fix or performance improvement

Godot stores imported project data under .godot. An editor session that predated the bell tower scripts could still have an old global_script_class_cache.cfg. In that state, starting the game caused a parse error because scripts such as game.gd referred directly to global types that were missing from the stale cache.

One room script, for example, inherited from a new global class by name:

extends TowerRoom

The test code also used the new classes for casts and enum access:

var sentinel := await _test_spawn_enemy(
    "res://src/enemies/clockwork_sentinel.tscn",
    Vector2(320, 300)
) as ClockworkSentinel

if sentinel._state == ClockworkSentinel.State.CHARGE:
    charged = true

Those references were valid after Godot refreshed its global class registry. Before that refresh, the parser could not resolve them.

CI missed the problem because the test workflow imported the project before running the suite. The import regenerated the cache, so CI always tested the healthy state. Local startup followed a different order and exposed the bug.

Refreshing or deleting .godot could repair one checkout, but it left the startup dependency in the code. I wanted the game to parse even before the editor rebuilt the cache.

Code

I merged the complete fix as PR #95 in the project's private repository. Since the repository is not publicly accessible, the relevant before-and-after code is included below.

The first change was to use a script path when a room inherited from one of the newly added classes:

extends "res://src/rooms/tower_room.gd"

For runtime checks, I loaded the script resource explicitly instead of asking the parser to resolve TowerRoom as a global name:

const TOWER_ROOM_SCRIPT := preload("res://src/rooms/tower_room.gd")

func _is_tower_room(node: Node) -> bool:
    if node == null:
        return false

    var script: Script = node.get_script() as Script
    while script != null:
        if script == TOWER_ROOM_SCRIPT:
            return true
        script = script.get_base_script()

    return false

The enemy tests now use their stable base type. They read the state through the object and compare it with an enum from an explicitly loaded script:

const CLOCKWORK_SENTINEL_SCRIPT := preload(
    "res://src/enemies/clockwork_sentinel.gd"
)

var sentinel: EnemyBase = await _test_spawn_enemy(
    "res://src/enemies/clockwork_sentinel.tscn",
    Vector2(320, 300)
)

if int(sentinel.get("_state")) == CLOCKWORK_SENTINEL_SCRIPT.State.CHARGE:
    charged = true

Temporary objects such as wax pools and bell shockwaves did not need a global type check at all. I added them to groups and tested the behavior that mattered:

if child.is_in_group(&"wax_pool"):
    pool_found = true

Effects and map marker helpers received the same explicit preload treatment. The fix covered 19 files with 81 additions and 33 deletions.

My improvements

I added a static check to stop cache-sensitive global names from returning outside their own class_name declarations:

CACHE_SENSITIVE='\b(TowerRoom|BelfrySpider|BellRingerWretch|CandleBearerSkeleton|CarrionCrow|ClockworkSentinel|GeneratedFx|MapMarkers|TowerImp|WaxSlime)\b'

CACHE_REFS=$(rg -n "$CACHE_SENSITIVE" src --glob '*.gd' \
  | grep -vE 'class_name (TowerRoom|BelfrySpider|BellRingerWretch|CandleBearerSkeleton|CarrionCrow|ClockworkSentinel|GeneratedFx|MapMarkers|TowerImp|WaxSlime)' \
  || true)

if [ -n "$CACHE_REFS" ]; then
    echo "FAIL(stale-cache): direct reference to a newly added global class"
    exit 1
fi

This check is intentionally narrow. class_name is still useful in the project, and I did not want to ban it. The guard covers the recently added classes that caused this startup regression.

I ran the full test command again on the current main branch while preparing this submission:

PASS(stale-cache)
PASS(rooms)
PASS(transition)
PASS(save)
PASS(progression)
PASS(gameover)
PASS(pause)
PASS(dash)
PASS(boss)
PASS(enemies)
PASS(walljump)
PASS(combo)
PASS(skins)
PASS(area3)
PASS(area3-enemies)
PASS(enemy-ai)
PASS(physics)
PASS(connections)
== ALL PASS ==

The asset check also passed for 911 media files, including 893 decoded PNGs and 110 frame sequences.

Clearing a bad cache would have repaired one checkout. The durable fix removes the undocumented requirement that the cache must be fresh before the project can be parsed. CI now checks the dependency directly, and the game no longer relies on editor state to reach its startup path.

Testing Cloudflare Cron Triggers Locally for Push Notification Workflows

hiro@ — Mon, 10 Aug 2026 00:44:05 +0000

This article is an English translation of the original Japanese article.

I use Cloudflare Workers Cron Triggers to send push notifications on the morning of practice days. The challenge was figuring out how to verify the entire workflow locally without waiting for the scheduled cron time.

In my implementation, I separate the Worker's scheduled event from the HTTP route that handles the notification logic.

Keep the scheduled handler thin

The Worker receives the cron event and calls an internal route handler.

export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext) {
    return handler.fetch(request, env, ctx);
  },

  async scheduled(_controller: ScheduledController, env: Env) {
    const request = new Request(
      "https://internal/api/cron/morning-reminder",
      {
        method: "POST",
        headers: { authorization: `Bearer ${env.CRON_SECRET}` },
      },
    );

    await handler.fetch(request, env);
  },
};

The key is not embedding date logic, user retrieval, and Expo Push API calls directly inside scheduled. Delegating to an HTTP route means the same logic can be triggered over HTTP, making local verification much easier.

Start Wrangler with scheduled test support

Locally, start Wrangler with the following option:

npx wrangler dev --test-scheduled

Append /__scheduled to the URL Wrangler displays.

curl "http://localhost:8787/__scheduled?cron=0+22+*+*+*"

Use the same cron expression in the cron query parameter. Cloudflare interprets cron in UTC, so don't write expressions based solely on JST.

Keep direct HTTP route access as a fallback

When you only want to verify recipient filtering, you can call the internal route directly.

curl -X POST http://localhost:8787/api/cron/morning-reminder \
  -H "Authorization: Bearer $CRON_SECRET"

This route validates CRON_SECRET. Rather than removing authentication for local development, I store a development value in .dev.vars. Production secrets never go into source control.

Separate actual sending from recipient extraction

If your local database has no schedules, participants, or push tokens for today, the cron will run but send zero notifications. When testing, verify in order:

Does scheduled reach the route?
Is the date correct after timezone conversion?
Are target schedules and participants retrieved?
Are users without push tokens filtered out?
Are external API results recorded?

The hard part of cron testing is not how to trigger it, but coordinating test data with the current time. Splitting the core logic into an HTTP route lets you verify event wiring and notification logic separately.

References

How much to share in a monorepo when building common features for web and mobile

hiro@ — Sun, 09 Aug 2026 00:13:56 +0000

This article is an English translation of the original Japanese article.

When I added an Expo app to an existing Next.js web service, I initially wanted to share as much code as possible. In practice, types and business rules share well, while UI and runtime dependencies are easier to manage separately.

SquadNote uses pnpm workspace and Turborepo, composed of apps/web, apps/mobile, and packages/*.

Current split

apps/
  web/       Next.js, Cloudflare Workers
  mobile/    Expo, React Native
packages/
  api/       tRPC and Zod shared parts
  db/        Drizzle schema
  design-tokens/

Root workspace configuration is simple:

packages:
  - "apps/*"
  - "packages/*"

turbo.json manages only build and typecheck dependencies. Rather than adding custom build steps for sharing, I started with a structure where each package exports TypeScript sources.

What I share

The biggest benefit came from tRPC types. Mobile type-imports the web AppRouter, using the same input and output.

import type { AppRouter } from "../../apps/web/src/server/api/root";

export const api = createTRPCReact<AppRouter>();

I also separated colors, spacing, and font sizes into @squadnote/design-tokens.

export { colors } from "./colors";
export { spacing } from "./spacing";
export { radius } from "./radius";

Business rules like waitlists become sharing candidates as pure functions with no dependency on React or DB. They are easy to test, and results do not diverge between web and mobile.

What I do not share

I do not share screen components. Next.js DOM and React Native View have different interactions, accessibility, and layout constraints, even when they look similar.

Authentication storage also differs:

Web: NextAuth cookie session
Mobile: SecureStore Bearer JWT

Both reach the same API, but sharing the login screen and token storage would require handling each environment's concerns with many branches.

Routing also has separate implementations for Next.js App Router and Expo Router. What I share is the meaning of organizationId or scheduleId, not a universal function wrapping router.push.

Criteria I use for decisions

Before moving code to packages, I check:

Does it depend on DOM, React Native, Node, or Cloudflare APIs?
Do web and mobile have the same reason to change?
Are branches increasing just to align props?
Can I verify meaning with unit tests alone?

Business rules and types tend to have the same reason to change. UI, even for the same feature, splits its change reasons by device.

The advantage of a monorepo is not being able to share everything. It is being able to move sharing boundaries later. I implement inside apps first, then extract to packages when specification drift becomes a bigger problem than duplication.

Converting Invite QR Codes to PNG and Sharing in React Native

hiro@ — Fri, 07 Aug 2026 02:46:34 +0000

This article is an English translation of the original Japanese article.

I made it possible to display the app invite link as a QR code and share it directly as an image.

For displaying the QR code I use react-native-qrcode-svg, for converting the View to PNG I use react-native-view-shot, and for the share sheet I use expo-sharing.

npx expo install expo-sharing react-native-view-shot
pnpm add react-native-qrcode-svg react-native-svg

Including the Organization Name in the Image, Not Just the QR Code

To ensure the content is clear from the shared image alone, I include both the QR code and the organization name in a single View.

const captureAreaRef = useRef<View>(null);

<View
  ref={captureAreaRef}
  collapsable={false}
  style={styles.captureArea}
>
  <Text style={styles.orgName}>{orgName}</Text>
  <QRCode
    value={inviteUrl}
    size={200}
    color={colors.foreground}
    backgroundColor={colors.card}
  />
</View>

I add collapsable={false} to prevent React Native from omitting the native View through optimization, which would make the captureRef target unavailable.

I also specify the background color. If I share a transparent image and the recipient's background is dark, the QR code margins and organization name can become hard to read.

Saving the View as PNG

For the share button, I pass the View's ref to captureRef.

const captured = await captureRef(captureAreaRef, {
  format: "png",
  quality: 1,
});

The returned value is the path to a temporary file. On Android, paths without a scheme can be returned, so I prepend file:// before sharing.

const uri = captured.startsWith("file://")
  ? captured
  : `file://${captured}`;

Sharing with `expo-sharing`

I check if the sharing feature is available on the device before opening the share sheet.

if (await Sharing.isAvailableAsync()) {
  await Sharing.shareAsync(uri, {
    mimeType: "image/png",
    dialogTitle: `Invite QR code for ${orgName}`,
  });
} else {
  await Share.share({ url: uri });
}

In the actual implementation, I also maintain state to prevent multiple share processes from starting on repeated taps.

const [sharing, setSharing] = useState(false);

const handleShareImage = async () => {
  if (sharing) return;
  setSharing(true);

  try {
    // captureRef and shareAsync
  } catch (error) {
    const message = error instanceof Error ? error.message : String(error);
    Alert.alert("Share failed", message);
  } finally {
    setSharing(false);
  }
};

While processing, I disable the button and switch the label to "Preparing to share". Because there is a slight delay from capture to the share sheet opening, this prevents it from appearing unresponsive.

What to Put in the QR Code

The QR code contains an HTTPS invite URL that can also be opened on the web, rather than a custom scheme.

const inviteUrl = `${config.apiUrl}/invite/${orgId}`;

On iOS, Universal Links are configured, so if the app is installed, the invite screen opens in the app. If not, the web version displays.

The QR image is not a screenshot. I limit the capture target to a dedicated View, so the modal close button and the "Share Image" button are not included in the image.

Full Implementation

Summarizing the key points, it looks like this:

export function InviteQrModal({ orgName, inviteUrl }: Props) {
  const captureAreaRef = useRef<View>(null);
  const [sharing, setSharing] = useState(false);

  const share = async () => {
    if (sharing) return;
    setSharing(true);
    try {
      const path = await captureRef(captureAreaRef, {
        format: "png",
        quality: 1,
      });
      const uri = path.startsWith("file://") ? path : `file://${path}`;
      await Sharing.shareAsync(uri, { mimeType: "image/png" });
    } finally {
      setSharing(false);
    }
  };

  return (
    <>
      <View ref={captureAreaRef} collapsable={false}>
        <Text>{orgName}</Text>
        <QRCode value={inviteUrl} size={200} />
      </View>
      <Pressable onPress={share} disabled={sharing}>
        <Text>{sharing ? "Preparing to share..." : "Share Image"}</Text>
      </Pressable>
    </>
  );
}

Rather than converting the QR code SVG directly to a file, capturing the displayed View as is made it easier to create a shared image that includes the organization name and description.

References

Managing production, preview, and runtimeVersion after introducing EAS Update

hiro@ — Thu, 06 Aug 2026 02:45:41 +0000

This article is an English translation of the original Japanese article.

I introduced EAS Update to an Expo app so that JavaScript and image changes could be delivered without store review. However, just getting the command to run is not enough for safe operation. You need channel and runtimeVersion to decide which builds receive updates.

Currently, I use three channels (development, preview, production) combined with the appVersion policy.

Fix channel to build profile

In eas.json, each build sets the target API and channel.

{
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal",
      "channel": "development",
      "env": {
        "APP_ENV": "development",
        "EXPO_PUBLIC_API_URL": "https://dev.squad-note.com"
      }
    },
    "preview": {
      "distribution": "internal",
      "channel": "preview",
      "env": {
        "APP_ENV": "production",
        "EXPO_PUBLIC_API_URL": "https://squad-note.com"
      }
    },
    "production": {
      "autoIncrement": true,
      "channel": "production"
    }
  }
}

Preview is an internal distribution build using the production API. You can verify OTA updates under the same data conditions before releasing to production. Development connects to the dev API, so its purpose differs from preview.

runtimeVersion matches appVersion

Expo config has this setting:

updates: {
  url: "https://u.expo.dev/<project-id>",
  fallbackToCacheTimeout: 0,
},
runtimeVersion: {
  policy: "appVersion",
},

If the app version is 1.0.11, only updates published for that runtime will be delivered. This setting makes it harder to mistakenly deliver new JavaScript to old binaries with different native configurations.

With fallbackToCacheTimeout: 0, the app does not wait indefinitely for updates at launch. Updates are applied at the next launch.

Changes delivered OTA versus changes sent to stores

Only changes that are complete with JavaScript and assets should be published as production updates.

cd apps/mobile
eas update --channel preview --message "Fix date display"
eas update --channel production --message "Fix date display"

The following changes require new binaries:

Adding or updating native libraries
Changes to plugins, ios, or android settings in app.config.ts
Expo SDK updates
App version changes that affect runtimeVersion

I do not decide that all dependency changes are OTA-incompatible. Instead, I check whether the package includes native code. If unclear, I route it through a normal build.

Actual release order

For routine fixes, I follow this sequence:

Verify locally and in Expo Go or development build
Publish to preview channel
Restart internal distribution build and verify
Publish the same change to production channel
For the next native change, increment version and submit to store

EAS Update speeds up releases but does not eliminate store builds. Channel is the delivery target, runtimeVersion is the compatibility boundary. After defining these two as separate roles, I integrated the update command into operations.

References

Ramen After Dark — A Steaming Comfort-Food Scene Drawn Entirely in CSS

hiro@ — Wed, 05 Aug 2026 05:58:03 +0000

This is a submission for Frontend Challenge — Comfort Food Edition, CSS Art.

Inspiration

My comfort-food moment is not only the ramen itself. It is the scene around it: a nearly empty counter, the city gone quiet, steam rising into warm light, and a paper-like moon outside the window.

I created Ramen After Dark to capture that pause at the end of the day. The palette uses deep brown-red night tones, warm ceramic, amber broth, and a soft gold moon so the bowl feels like the brightest and safest place in the frame.

Demo

takahiro-saeki.github.io

Journey

Constructing the bowl from basic shapes

The artwork contains no images, SVG illustration paths, canvas, or JavaScript. The large bowl begins as a rounded rectangle with a thick ceramic border. A second oval creates the broth surface and clips all of the toppings.

Each ingredient is another small CSS shape:

The egg is an irregular rounded rectangle with an inset yolk.
Nori uses dark rectangles with crossing gradients for texture.
Chashu uses rounded shapes and radial gradients.
Noodles are border arcs layered across the broth.
Scallions are tiny bordered ellipses.
Naruto uses a pale rounded shape with a partial pink ring.
Chopsticks are two long gradients rotated across the scene.

The city silhouette is a row of simple blocks. The moon uses nested circles and radial gradients. Even the ceramic pattern is made from three square borders rotated by 45 degrees.

Creating depth without a drawing API

The main challenge was preserving the order of overlapping elements. Nori needs to sit behind the noodles, the egg and pork need to remain readable inside a shallow broth ellipse, and the chopsticks must cross both the toppings and bowl rim.

I used isolated stacking contexts and a deliberately small z-index scale. Shadows beneath the bowl and highlights inside the broth create depth without changing the underlying geometry.

Letting only the steam move

Three steam trails are the only animated elements. They use slow opacity, vertical translation, and horizontal scale changes. Their negative delays keep them from moving in sync.

The rest of the illustration remains still so the motion supports the subject instead of distracting from it. When the visitor prefers reduced motion, the shared stylesheet effectively disables the animation.

Making one composition work across screen sizes

The artwork uses a 16:10 stage on larger screens and a taller 4:5 stage on mobile. The bowl, toppings, chopsticks, steam, and moon use percentages or clamped sizes, allowing the composition to reframe instead of simply shrinking.

I tested it at 375 and 1440 pixels and verified that the art frame stays within the viewport without horizontal scrolling.

What I Am Proud Of

The bowl remains recognizable from the full composition down to mobile size, even though every ingredient is an ordinary HTML element. I also like that the artwork became the visual foundation for a separate functional restaurant landing page rather than remaining an isolated experiment.

This challenge was a good reminder that CSS art is closely related to interface work: both rely on hierarchy, constraints, layering, responsive composition, and knowing when a detail is helping the whole.

The complete project is available under the MIT license.

DEV Community: hiro@

Release process for continuously delivering a personal dev app to TestFlight

Separate version and build number

Determine change type before release

production build and submit

What to verify in TestFlight

Leave procedure in commits

References

Why Waitlist Promotion Should Be Determined Server-Side, Not Client-Side

createdAt does not reflect participation order

Merge members and guests into a single queue

Find promotions by comparing before and after

Use API response for display

Design evolution toward using the same auth and permission model in Next.js and Expo

Web kept NextAuth cookies

Mobile goes through web OAuth

Align to the same user format in tRPC context

Separate authentication and authorization

401 is handled once on mobile side

Switching Between Web URLs and App Deep Links for LINE In-App Browser

Not Directly Sharing Custom Scheme

Separating Public and Member Pages

The Parameter Is Not for Opening the App

Separating Share Message from URL

References

Data design for attendance management with capacity, waitlist, and proxy input

Core columns in attendance

attendingSince separate from createdAt

Guests consume the same capacity

Record proxy input history

Capacity changes are treated as the same event as attendance changes

Supporting Language Switching for Date Formats, Not Just Text, with i18next

Three Language Settings

Not Handwriting Dates

Gradually Increasing Translation Coverage

References

The Stale Godot Class Cache Bug That Passed CI but Broke Local Startup

Project overview

Bug fix or performance improvement

Code

My improvements

Testing Cloudflare Cron Triggers Locally for Push Notification Workflows

Keep the scheduled handler thin

Start Wrangler with scheduled test support

Keep direct HTTP route access as a fallback

Separate actual sending from recipient extraction

References

How much to share in a monorepo when building common features for web and mobile

Current split

What I share

What I do not share

Criteria I use for decisions

Converting Invite QR Codes to PNG and Sharing in React Native

Including the Organization Name in the Image, Not Just the QR Code

Saving the View as PNG

Sharing with expo-sharing

What to Put in the QR Code

Full Implementation

References

Managing production, preview, and runtimeVersion after introducing EAS Update

Fix channel to build profile

runtimeVersion matches appVersion

Changes delivered OTA versus changes sent to stores

Actual release order

References

Ramen After Dark — A Steaming Comfort-Food Scene Drawn Entirely in CSS

Inspiration

Demo

Journey

Constructing the bowl from basic shapes

Creating depth without a drawing API

Letting only the steam move

Making one composition work across screen sizes

What I Am Proud Of

`createdAt` does not reflect participation order

Sharing with `expo-sharing`