Walk Through an App Store Submission Without Writing Code — Sticker Packs as a Dress Rehearsal

The app runs. Rork built the screens, it works on the phone in your hand, and yet it is still not on the App Store. I have heard this more than once, and the thing blocking it is almost never the code. It is everything that happens afterward, inside App Store Connect.

When I started publishing wallpaper apps on my own, the implementation was not what ate my time either. Answering the age rating questionnaire. Filling in the App Privacy declarations. Getting screenshots rejected over dimensions. Submitting, waiting, hearing back. Going into your first real app without having seen that loop means burning energy on things that have nothing to do with whether the app is any good.

An iMessage sticker pack is a way to see the loop early. It ships with zero lines of code, and App Store Connect still asks you for nearly everything a full app requires.

One honest caveat first: this is not a way to make money.

Accept the revenue constraint up front

A standalone sticker pack cannot use In-App Purchase. It cannot carry ads. Your only options are free, or paid once up front.

This is not a matter of extra work — it is what the format is. If you want purchases, media sharing, or Apple Pay, you are no longer building a sticker pack. You are building an iMessage app, which is a different thing entirely.

So if you approach a sticker pack as a small side income, you will be disappointed. I have watched people make that mistake.

Now turn it around. No revenue means no revenue paperwork. With no ad SDK, the App Privacy section becomes remarkably light. With no purchases, StoreKit, price tiers, and subscription review criteria never enter the picture.

What drops away is the heavy, app-specific part of submission. What remains is the skeleton every app has to clear. As teaching material, that is better. With fewer variables in play, wherever you get stuck is a real gap in what you know — not noise.

What you actually have to produce

The three items in bold are what make sticker packs their own animal. The two icon sets catch nearly everyone the first time: one for the App Store for iMessage, one for the App Store on iPhone and iPad. Build a single set out of habit and the upload will tell you something is missing.

Two places the artwork will stop you

Apple offers three sticker dimensions. Because you export at @3x, the actual files come out at 300×300 px, 408×408 px, or 618×618 px.

Here is the first trap: you pick one of the three and every sticker in the pack has to match it. You cannot mix large and small. One asset that happens to be a different size because of how you made it will not slide through.

The second is weight. No single sticker may exceed 500KB. Static art has room to spare. Add animation and the ceiling becomes real.

Both are decisions to make before you lay out any artwork. Fixing them afterward means redoing the set.

With wallpaper apps I settled on keeping one oversized master and mechanically scaling down from it. The same shape works here. Treat 618×618 as the source of truth and derive downward, and changing your mind later just means going back to the master.

Checking the exports is more reliable in bulk than by eye. On macOS this needs nothing installed:

#!/bin/bash
# Normalize PNGs under stickers/ to 618x618 and flag anything over 500KB
# Usage: bash check-stickers.sh stickers
 
SRC="${1:-stickers}"
OUT="$SRC/out"
SIZE=618
LIMIT=512000  # 500KB = 500 * 1024
 
mkdir -p "$OUT"
over=0
 
for f in "$SRC"/*.png; do
  [ -e "$f" ] || { echo "No PNGs found in: $SRC"; exit 1; }
  name=$(basename "$f")
  # Fit the long edge to 618, preserving aspect ratio (sips ships with macOS)
  sips -Z "$SIZE" "$f" --out "$OUT/$name" > /dev/null 2>&1
 
  bytes=$(stat -f%z "$OUT/$name")
  dim=$(sips -g pixelWidth -g pixelHeight "$OUT/$name" | awk '/pixel/ {printf "%s", $2" "}')
  if [ "$bytes" -gt "$LIMIT" ]; then
    echo "❌ $name : ${bytes} bytes (${dim}) — over 500KB"
    over=$((over + 1))
  else
    echo "✅ $name : ${bytes} bytes (${dim})"
  fi
done
 
echo "---"
if [ "$over" -gt 0 ]; then
  echo "$over sticker(s) exceed 500KB. Revisit your export settings."
  exit 1
fi
echo "All stickers meet the requirements."

sips -Z fits the long edge to the value you give it. Feed it a non-square asset and you will not get 618×618 — only the long edge lands on 618. That is why the script prints the resulting dimensions: anything other than 618 618 means the source art was never square. Let that pass quietly and Xcode will be the one to tell you.

Because it returns an exit code, running it after every asset swap keeps a size rejection from surfacing right before submission.

What one lap actually teaches you

Ship a single sticker pack and you are left holding a few things.

A Developer Program enrollment and certificates already sorted out. The experience of creating an App Store Connect record yourself. The memory of answering the age rating questions in the context of your own app. The shape of an App Privacy declaration when you collect nothing at all. And a felt sense of how long review actually takes.

That last one matters most. Knowing the wait in your body changes how you plan a real release. Without it, most people estimate optimistically and everything downstream slips.

Screenshots are the quiet one. A sticker pack's screenshots have to show stickers being used inside a conversation — a scene, not a feature callout. That instinct transfers directly to store art for a real app. On the mechanics of shooting fewer of them, I wrote up my approach in Six-Point-Nine Inches Is All You Need to Shoot — A Screenshot Pipeline That Cuts the Count for Multilingual Apps.

The fork comes when you want revenue

After one lap you will probably want more. The stickers shipped, but nothing monetizes.

To put purchases or media sharing behind stickers, you need an iMessage app rather than a standalone pack. That is where code starts. Rork Max reaching into iMessage lives at exactly this layer — bringing your app's world into the conversation itself. I covered the implementation side in Building an iMessage Extension with Rork Max — Bringing Your App's World Into the Conversation.

I would argue this order is the gentler one. Clear the submission skeleton with a sticker pack, learn where you stumble, then move to the format that requires code. Reverse it and implementation bugs arrive at the same moment as submission confusion, with no way to tell which is which.

Wrapping up

A sticker pack is not a revenue play. With no purchases and no ads, it never will be.

What it gives you instead is a full lap around App Store submission without writing a line of code, and a clear picture of the gaps in your own knowledge.

If your Rork app is sitting just short of the store right now, gather ten pieces of art, normalize them to 618×618, and put one through. There is almost nothing to lose if it gets rejected. What you gain is a map of the lap you will otherwise be walking blind.

I still remember what tripped me up on my own first pass. That detour is why the submissions after it felt calm.