⬡ Dev Tools/2026-06-26Intermediate

Watermark Only the Shared Image in Your Rork Wallpaper App

In a Rork-generated Expo wallpaper or image app, keep saved images untouched and burn a watermark only into the share export, shown two ways — react-native-view-shot and Skia — with the resolution-loss pitfalls to avoid.

Rork⁴⁵⁵ Expo¹⁰⁸ react-native-view-shot Skia wallpaper app²²

✦ Premium Article

Running a wallpaper app for a long time, the moment a user's image spreads across social media is the most rewarding — and also the one where it feels wasteful that it travels with no trace of where it came from. As an indie developer who has run wallpaper and calm-and-wellness apps on the App Store and Google Play, I can say that a small app name in the corner of one shared image reliably brings people who search and install from it.

But get the watermark wrong and it backfires. Burn it into the wallpaper a user saves to their own device and "there's a logo on my lock screen" turns into one-star reviews. The aim is narrow: keep the saved copy clean and composite a watermark only when exporting for a social share. Building on the Expo (React Native) code Rork emits, here is how to split those two outputs.

Separating saved versus shared images

Decide the policy first. The app handles one "original" image, but it has two exits.

What goes to device save and wallpaper-set is the original, untouched. No watermark.
Only when sharing to social or another app do you generate a new image with the watermark composited on top of the original, and hand that to the share sheet.

Insert this fork one step before the share call and you keep the discovery path without hurting the experience. I recommend this split above all else. Treat the watermark as something added "for the people it spreads to," not "for the user," and the design stops wandering.

The quick path: composite and capture with view-shot

The lightest approach is to display the image and the watermark stacked on screen and capture that region, using react-native-view-shot.

import { useRef } from "react";
import { View, Image, Text, StyleSheet } from "react-native";
import ViewShot, { captureRef } from "react-native-view-shot";
import * as Sharing from "expo-sharing";
 
export function WatermarkedShare({ uri }: { uri: string }) {
  const shotRef = useRef<ViewShot>(null);
 
  async function shareWithWatermark() {
    // Capture the offscreen-style view at the original resolution
    const out = await captureRef(shotRef, {
      format: "jpg",
      quality: 0.95,
      result: "tmpfile",
    });
    await Sharing.shareAsync(out);
  }
 
  return (
    <ViewShot ref={shotRef} style={styles.canvas}>
      <Image source={{ uri }} style={styles.base} resizeMode="cover" />
      <Text style={styles.mark}>made with Aurora Wallpapers</Text>
    </ViewShot>
  );
}
 
const styles = StyleSheet.create({
  canvas: { width: 1080, height: 1920 },
  base: { width: 1080, height: 1920 },
  mark: {
    position: "absolute", right: 24, bottom: 28,
    color: "rgba(255,255,255,0.85)", fontSize: 28, fontWeight: "600",
  },
});

The upside is speed, but there is a pitfall. captureRef essentially captures at the screen's pixel density, so even with width: 1080 the real size shifts on Retina devices, and the export comes out blurry or oddly huge. With a high-resolution wallpaper as the original, that screen dependence shows up directly as quality loss. For a prototype or a lower resolution view-shot is fine, but for a wallpaper app that needs exact resolution I recommend the next approach.

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN

✦Design a two-path flow where saved images stay untouched and only the social share export gets a branded watermark

✦Get both the fast view-shot approach and the resolution-preserving Skia approach in working code, with a rule for when to use which

✦Pre-empt the post-launch quality issues — blurry marks, clipped edges, and image degradation when shared

Secure payment via Stripe · Cancel anytime

✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

Unlock all articles with Membership →

Preserving resolution: composite offscreen with Skia

With @shopify/react-native-skia you can composite at a specified pixel count without putting anything on screen. Its strength is burning in only the watermark while dropping none of the original resolution.

import {
  Skia, Canvas, Image as SkImage, Text as SkText,
  useImage, useFont,
} from "@shopify/react-native-skia";
 
export async function renderWatermarked(
  srcUri: string, width: number, height: number
): Promise<string> {
  const image = await Skia.Data.fromURI(srcUri)
    .then((d) => Skia.Image.MakeImageFromEncoded(d));
  if (!image) throw new Error("decode failed");
 
  // Offscreen surface at the same resolution as the original
  const surface = Skia.Surface.MakeOffscreen(width, height)!;
  const canvas = surface.getCanvas();
 
  canvas.drawImageRect(
    image,
    Skia.XYWHRect(0, 0, image.width(), image.height()),
    Skia.XYWHRect(0, 0, width, height),
    Skia.Paint()
  );
 
  const font = Skia.Font(/* typeface */ undefined, Math.round(width * 0.026));
  const paint = Skia.Paint();
  paint.setColor(Skia.Color("rgba(255,255,255,0.85)"));
  canvas.drawText("made with Aurora Wallpapers", width * 0.04, height - height * 0.03, paint, font);
 
  surface.flush();
  const snapshot = surface.makeImageSnapshot();
  const base64 = snapshot.encodeToBase64();   // turn into a file and share downstream
  return base64;
}

The key is to size the watermark text and padding by ratio — like width * 0.026 — rather than fixed pixels. The same function then handles a tall wallpaper and a square icon asset alike, and you avoid clipping at the edges. In my case the font landed around 2.6% of the width and the bottom-right padding around 3% of the height.

Which one to choose

The two approaches trade speed against quality. Here is how I split them.

view-shot suits the prototype stage where you just want something running, or cases where the social timeline view is the goal and high resolution is not demanded. It takes a few dozen lines, plenty for a first check.

Skia suits a production wallpaper app, where the original resolution is everything and no artifacts may show even at 1:1 on the destination. The setup cost rises, but you hold the reins on quality. For a long-lived app I recommend Skia.

Degradation to kill before release

The trouble with watermarking is that people only notice "the quality is somehow bad" after you ship. Before production I always check three things.

Does the exported image's real pixel count match the original? Going through view-shot it quietly becomes 2x or 0.5x.
Is JPEG quality dropped too far? Set quality below 0.8 and banding shows in sky gradients. I keep mine at 0.92 to 0.95.
Watermark opacity. Around 85% stays visible without being intrusive; at 100% it shouts and people stop sharing.

Connecting spread to a paid path

The watermark is the entry point for brand exposure, but it is wasteful to stop there. Embed not just "app name" but a quiet hint of the product's world in the share watermark, and incoming users tend to stay rather than bounce.

In my own apps, free users' share images carry the watermark, while paid members unlock a watermark-free export. Being able to remove the mark becomes a small reason to pay, working as a revenue line separate from AdMob ad income. Frame the watermark not as a "restriction" but as "a modest thank-you in exchange for free use," and users accept it more easily.

Start by adding one export fork into your app's share flow. Leave the original clean and change only the exit. That single move noticeably changes the quality of both the spread and the inflow.

Thank You for Reading

Rork Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.