🛹 Sketchy - Skateboard Companion App

The stack at a glance

Sketchy is the latest version of a skateboard companion app I started four years ago, back when I was just getting into mobile development. The original web app still lives at skate-dice.com, the mobile sibling was called SkateDex, and looking back at the early designs and the original feature set, you can tell exactly how far both my taste and the React Native tooling have come since. The version on the stores today is a fresh, ground-up rebuild on the current Expo SDK, and I'm stoked on where it's landed.

What it is now is a multi-tab companion app with an offline trick journal, a skate-spot finder, a daily challenge notification, a quiz, a level-based skill ladder, and an optional Pro upgrade that unlocks the extra 🔥 content. The footprint is intentionally small. Everything below sits on top of Expo SDK 55 and React Native 0.83, and Apple Developer and Play Console are the only ongoing paid services; Sentry, PostHog, RevenueCat, and EAS all sit comfortably inside their free tiers for an app this size.

A few of those choices are worth a sentence on their own. Expo SDK 55 brings React 19 and React Native 0.83.6. Since RN 0.82 the New Architecture is the only architecture, so on 0.83 there isn't a "legacy mode" to fall back to even if you wanted one. The React Compiler is enabled via experiments.reactCompiler: true in app.config.ts, so I get auto-memoisation across the whole app without writing a single useMemo. Reanimated 4 brings worklets-core and a meaningful step up in animation performance, especially on Android.

What "the New Architecture" actually means

The phrase "New Architecture" gets thrown around in Expo and React Native release notes a lot, and for a long time it felt like one of those things you opt into, flip a flag for, then chase obscure native build errors until you give up. As of React Native 0.76 it became the default, and as of 0.82 it became the only architecture: the legacy bridge has been removed and newArchEnabled=false is now silently ignored. Sketchy ships on RN 0.83, so it's a generation past the point where any of this is optional.

TYPESCRIPT
1// ───── BEFORE: Native Modules (legacy bridge) ─────
2import { NativeModules } from 'react-native'
3
4const { MyModule } = NativeModules
5
6// every call is async, JSON-encoded over the bridge,
7// and the JS-side types are whatever you hand-write
8const result = await MyModule.add(1, 2)

TYPESCRIPT
1// ───── AFTER: TurboModule spec (NativeMyModule.ts) ─────
2import type { TurboModule } from 'react-native'
3import { TurboModuleRegistry } from 'react-native'
4
5export interface Spec extends TurboModule {
6  add(a: number, b: number): number
7}
8
9export default TurboModuleRegistry.getEnforcing<Spec>(
10  'MyModule',
11)
12
13// callsite is just a typed function call:
14//   const result = MyModule.add(1, 2)

OBJECTIVEC
1// ───── BEFORE: Native Module on iOS (MyModule.m) ─────
2@implementation MyModule
3RCT_EXPORT_MODULE();
4
5RCT_REMAP_METHOD(add,
6                 a:(double)a
7                 b:(double)b
8                 resolver:(RCTPromiseResolveBlock)resolve
9                 rejecter:(RCTPromiseRejectBlock)reject) {
10  resolve(@(a + b));
11}
12@end

OBJECTIVEC
1// ───── AFTER: TurboModule on iOS (MyModule.mm) ─────
2@implementation MyModule
3RCT_EXPORT_MODULE()
4
5- (NSNumber *)add:(double)a b:(double)b {
6  return @(a + b);
7}
8
9// Codegen produces NativeMyModuleSpecJSI from the .ts spec
10// and you hand back an instance from getTurboModule(...)
11@end

Visually, the shift from old to new is a fatter middle. The legacy stack put a single async bridge plus a separate Paper renderer between JS and native. The new stack splits that work into four pillars that each do less, faster:

The practical difference for an app like Sketchy is that synchronous native calls are actually synchronous, which is the thing expo-sqlite leans into hard. The whole journal database is read and written with execSync, getAllSync, and runSync calls, which only really works because there's no JSON-serialised bridge round-trip in the way. On the old bridge, that would have been a UI thread killer the moment the database held more than a handful of rows.

Turning the React Compiler on

The React Compiler is a build-time transform that figures out which values inside a component are stable and inserts the equivalent of useMemo and useCallback for you. On Expo SDK 55 you get it by adding a single flag to app.config.ts:

TSX
1export default ({ config }: ConfigContext): ExpoConfig => ({
2  ...config,
3  name: 'Sketchy',
4  runtimeVersion: majorVersion, // OTA channel pinning
5  experiments: {
6    reactCompiler: true, // free perf, no code changes
7  },
8  plugins: [
9    'expo-router',
10    'expo-sqlite',
11    'expo-sharing',
12    'expo-updates',
13    ['expo-location', { ... }],
14    ['expo-sensors', { ... }],
15    ['expo-notifications', { ... }],
16  ],
17})

The practical effect is that the compiler takes most of the memoisation decisions off your hands. New components in Sketchy don't reach for useCallback when a function is passed into a child, and they don't wrap derived values in useMemo unless there's a real reason. The trade-off is that you stop being able to read a component and tell at a glance which values are stable, which I'm OK with for an app this size, but I'd think harder about it on a larger codebase with multiple contributors and stricter performance budgets.

It's still flagged as experiments.reactCompiler in Expo SDK 55, and the reason is less "the compiler is buggy" and more "the compiler is stricter than the runtime ever was." The compiler enforces the Rules of React (no conditional hooks, no mutating props, no reading refs during render, no impure component bodies) and any pre-existing codebase that's been quietly violating those rules will start surfacing bugs once it's on. The compiler itself is stable enough to ship; the tooling around catching those violations ahead of time (eslint-plugin-react-compiler, the strict lint configuration) is what's still maturing, and the React team is being deliberately conservative about removing the flag while real codebases finish surfacing edge cases.

The trick journal, stored in expo-sqlite

The journal is the most data-heavy screen in Sketchy. It's a calendar-driven log of every skate session, with a simple three-state status per trick (tried, landed, learnt). When a trick is marked as learnt it gets pinned to a permanent mastery list, and anything that's landed or learnt rolls up into a "bag of tricks" pool that the Quick Play screen draws from. It needs to be fast, offline, and resilient across app updates, and that ruled out anything more exotic than SQLite.

The whole database is four tables. sessions is the parent; session_tricks hangs off it with a unique constraint on (session_id, trick_name) so a single trick can't be landed twice in the same session. trick_mastery records the first time a trick was learnt across all sessions. bag_tricks is the read-optimised view that the dice and quick-play screens pull from.

The expo-sqlite API in SDK 55 is fully synchronous, which is the thing that surprised me most coming back from the older callback-based version. There's no await, no transactions wrapper, no callbacks. You open a database handle once, set the SQLite settings you want, and read and write inline:

TYPESCRIPT
1import * as SQLite from 'expo-sqlite'
2
3let _db: SQLite.SQLiteDatabase | null = null
4
5const db = (): SQLite.SQLiteDatabase => {
6  if (!_db) {
7    _db = SQLite.openDatabaseSync('journal.db')
8    _db.execSync('PRAGMA journal_mode = WAL')
9    _db.execSync('PRAGMA foreign_keys = ON')
10    _db.execSync(`
11      CREATE TABLE IF NOT EXISTS sessions (
12        id INTEGER PRIMARY KEY AUTOINCREMENT,
13        date TEXT NOT NULL,
14        location TEXT,
15        notes TEXT,
16        created_at TEXT NOT NULL
17      )
18    `)
19  }
20  return _db
21}

Reads look like this. No async, no error boundary gymnastics, just a function that returns rows:

TYPESCRIPT
1export const getSessionsForMonth = (
2  year: number,
3  month: number,
4): JournalSession[] => {
5  const prefix = `${year}-${String(month).padStart(2, '0')}`
6  return db().getAllSync<JournalSession>(
7    'SELECT * FROM sessions WHERE date LIKE ? ORDER BY date DESC',
8    [`${prefix}%`],
9  )
10}

And writes use the same shape. Sketchy's most common write is the upsert that changes a trick's status mid-session, which falls naturally out of the unique constraint on the table:

TYPESCRIPT
1db().runSync(
2  `INSERT INTO session_tricks (session_id, trick_name, status)
3   VALUES (?, ?, ?)
4   ON CONFLICT(session_id, trick_name)
5   DO UPDATE SET status = excluded.status`,
6  [sessionId, trickName, status],
7)

The performance budget for this kind of thing has gotten generous on the New Architecture. Sketchy hasn't been live long enough for me to stress the schema with a full year of real data, but the sync expo-sqlite path on JSI is fast enough on the small-to-medium reads I have run that I'm not pre-emptively reaching for pagination or caching. If you're coming from AsyncStorage, the difference in feel is meaningful once you're past the point where a single JSON blob is the right shape for your data.

When to pick sqlite, AsyncStorage, or MMKV

The three local-persistence options on React Native each fit a different shape of data, and the rule of thumb that's served me well is to pick by data shape, not by perceived complexity.

AsyncStorage is the default. Async API, one JSON blob per key. It's the right pick for tiny pieces of state where you'd otherwise be over-engineering: a feature flag, the last-seen onboarding step, a single user preference. The cost when you outgrow it is that you read and write whole blobs even when you only need one field, and any structure you put inside has to serialise and deserialise on every access.

MMKV is the same shape as AsyncStorage (key-value) but backed by memory-mapped files rather than per-call disk I/O. Public benchmarks put it well above an order of magnitude faster on reads and writes, and it has a sync API. If you've got a lot of small keys read on every screen mount and AsyncStorage is showing up in your perf traces, the migration is mostly a search-and-replace.

expo-sqlite wins the moment your data has actual structure: lists, foreign keys, aggregations, range queries. The whole reason the journal lives in sqlite is that rolling sessions and tricks up into mastery and bag-tricks tables is a relational problem, and reading "all sessions in March 2026 where the user landed at least one trick" is a query, not a JSON walk.

On Sketchy, the split is a bit messier than the rule of thumb would suggest. The journal is sqlite. The OSM spot cache (with its timestamp-based TTL) is AsyncStorage. The notification preference and daily challenge state are AsyncStorage. The quiz high-scores and per-category stats are AsyncStorage. The progression state (completed tricks, unlocked levels) is AsyncStorage too.

The quiz scores and progression state could (and probably should) live in sqlite, since they have structure: per-category stats, ordered level lists, completed-trick sets. They're in AsyncStorage because that was the fastest path while shipping the first version, and the data volume is small enough that the cost hasn't bitten yet. If I were shipping v2, that's the likeliest migration. The rest (TTL caches, single-key prefs) is in the right place.

Free maps, free spots: OpenStreetMap end to end

The Spot Finder shows nearby skateparks, street spots, and skate shops on a map. The default for a React Native app is Apple Maps on iOS and Google Maps on Android via react-native-maps, which is fine until you start thinking about pricing tiers, attribution, and data ownership. Sketchy goes a different way and uses the free OpenStreetMap ecosystem end to end: free tiles, free geocoding, free spot data, no API keys.

The map is Leaflet rendered inside a react-native-webview, with the leaflet.markercluster plugin grouping nearby markers as you zoom out so the screen never gets noisy. The native side hands the WebView a small bridge: it injects markers when the user moves the map, and the WebView posts back the new bounding box and tap events.

TYPESCRIPT
1// React Native side
2webViewRef.current?.injectJavaScript(
3  `renderSpots(${JSON.stringify(spots)}); true;`,
4)
5
6// Leaflet side, posted back to RN
7map.on('moveend', () => {
8  const b = map.getBounds()
9  window.ReactNativeWebView.postMessage(
10    JSON.stringify({
11      type: 'bounds',
12      bbox: [
13        b.getSouth(), b.getWest(),
14        b.getNorth(), b.getEast(),
15      ],
16    }),
17  )
18})

Spot data comes from Overpass, the read endpoint for the OpenStreetMap database. The query asks for everything tagged leisure=skate_park, sport=skateboard, or shop=skateboard, plus a fuzzy name match for shops that sell decks but haven't been tagged with the sport:

TYPESCRIPT
1const query = `
2  [out:json][timeout:30];
3  (
4    nwr["leisure"="skate_park"](${bbox});
5    nwr["sport"="skateboard"](${bbox});
6    nwr["shop"="skateboard"](${bbox});
7    nwr["shop"]["name"~"skate",i](${bbox});
8  );
9  out center;
10`
11
12const response = await fetch(
13  'https://overpass-api.de/api/interpreter',
14  {
15    method: 'POST',
16    body: `data=${encodeURIComponent(query)}`,
17  },
18)

Overpass is free but rate-limited, so any large bounding box gets split into a 3x3 tile grid, fetched sequentially with a short pause between requests, and merged into the marker set as each tile lands so the map starts populating before everything finishes. Results get cached in AsyncStorage with a 30-minute TTL keyed off coordinates rounded to a ~1km grid, so re-opening the same area an hour later doesn't trigger another round-trip. The "search for a place" flow uses Nominatim, OpenStreetMap's free geocoder, with two parallel queries per search (one biased towards skateparks, one bare) deduped by rounded lat/lon.

EAS Build, EAS Update, EAS Submit

Sketchy has three build profiles in eas.json:

JSON
1{
2  "build": {
3    "development": {
4      "developmentClient": true,
5      "distribution": "internal",
6      "android": { "buildType": "apk" }
7    },
8    "preview": {
9      "channel": "preview",
10      "distribution": "internal",
11      "android": { "buildType": "apk" }
12    },
13    "production": {
14      "channel": "production-v1.0.0",
15      "autoIncrement": true,
16      "distribution": "store",
17      "ios": { "resourceClass": "m-medium" },
18      "android": { "buildType": "app-bundle" }
19    }
20  }
21}

The development profile builds a dev client APK I can side-load onto a real Android device. The preview profile is the one TestFlight reviewers and friends-and-family install. The production profile is what the App Store and Play Store get. autoIncrement bumps the build number every time, and appVersionSource: remote means the semantic version lives on EAS's servers rather than in the repo, which removes a whole category of merge-conflict-induced shipping accidents.

BASH
1bun run eas-ota:prod
2# bunx eas-cli update --channel <current production channel from eas.json>

JSON
1"submit": {
2  "production": {
3    "ios": {
4      "appleId": "...",
5      "ascAppId": "..."
6    },
7    "android": {
8      "serviceAccountKeyPath": "...",
9      "track": "internal"
10    }
11  }
12}

Libraries that pulled their weight

Sketchy keeps the dependency list small on purpose. A few of the choices below are worth a sentence each on what they buy you and why they're in the stack.

Reanimated 4 + worklets-core

Sketchy leans on animation heavily. Twelve Lottie animations are bundled into the app, there's a custom animated splash on top of the static one, and Reanimated worklets drive the climb-cards flip, the spire-map progression, the floor-reward celebration, the run-result modal, and the firing-line generator. All the worklet-driven screens are useSharedValue and useAnimatedStyle end-to-end.

Quick mental model on why that matters. React Native runs on two main threads at runtime: the JS thread, where your bundle and React reconciliation live, and the UI thread, where the native renderer paints frames. Anything that needs to update a view at 60fps has to either run on the UI thread directly or cross to it without going through the JS thread, because a busy reconciler will starve the animation.

JS threadYour bundle, React reconciliation

• app code & state
• React reconciliation
• sqlite / storage / fetch
• runOnJS callbacks

UI threadWhere the renderer paints

• Fabric layout + paint
• native gesture routing
• view updates

UI worklet runtimeSecond JS runtime, lives on the UI thread

• functions marked 'worklet'
• useAnimatedStyle bodies
• useDerivedValue
• gesture-handler worklets
• shared values

Worklets are how Reanimated keeps an animation rendering at 60fps even when the JS thread is busy. The body lives in the worklet runtime; the UI thread paints; the JS thread doesn't have to be involved per frame.

Reanimated's answer is worklets: small JS functions the library lifts off the JS thread and runs on a second JS runtime that lives on the UI thread. The body of useAnimatedStyle, useDerivedValue, or any function you mark with the 'worklet' directive runs there. The JS thread is only involved at setup, and at the points where you cross back explicitly via runOnJS.

Reanimated 3 shipped that runtime baked into the library. Reanimated 4 extracted it into a standalone package called react-native-worklets. Same idea, less overhead per worklet at registration time, faster cold start of any screen using Reanimated, and the runtime can now be shared with other libraries that need worklet semantics. Margelo's react-native-worklets-core is a parallel runtime originally built for vision-camera and Skia, which fills a similar role for those libraries. On Sketchy the practical effect is that the climb-cards flip and the firing-line generator keep their frame budget even when the JS thread is busy hitting sqlite or resolving the next trick. That gap is most visible on Android, where the JS thread is more easily starved than on iOS.

expo-sensors and expo-haptics

Shake-to-roll is the small detail that turned the dice screen from "fine" into "fun." It's DeviceMotion from expo-sensors sampled every 100ms with a 1.5-second debounce, so a bumpy car doesn't trigger a roll, and an expo-haptics impactAsync with the heavy style fires on success. Two tiny libraries, two lines of config in app.config.ts, and the screen feels like a native dice app instead of a React Native one 🔥.

TYPESCRIPT
1await Notifications.scheduleNotificationAsync({
2  content: {
3    title: "Today's challenge: ${trick.name}",
4    body: trick.description,
5  },
6  trigger: {
7    hour: 9,
8    minute: 0,
9    repeats: true,
10  },
11})

TSX
1// src/components/skate-text.tsx
2const styles = StyleSheet.create({
3  hero: {
4    fontSize: 52,
5    lineHeight: 56,
6    fontFamily: 'Bangers_400Regular',
7    paddingRight: 12, // bleed budget
8    minWidth: '100%', // stop shrink-to-glyph
9  },
10  display: {
11    fontSize: 36,
12    fontFamily: 'Bangers_400Regular',
13    paddingRight: 10,
14    minWidth: '100%',
15  },
16  title: {
17    fontSize: 28,
18    fontFamily: 'Bangers_400Regular',
19    paddingRight: 8,
20    minWidth: '100%',
21  },
22  // ...etc per variant
23})

Conclusion

The thing I keep coming back to with Sketchy is how little of the work was plumbing. Expo SDK 55 plus EAS plus the New Architecture means most of the decisions that used to eat days are now defaults. I spent almost all of my time on the parts that actually shape the product: the dice mechanics, the trick climber's progression curve, the journal data model, the shake-to-roll feel, the Bangers font clipping fights 🤦, curating the 8,000-plus trick catalogue, and (the rabbit hole that ate the most evenings) modelling skate stances and flow properly so the generators know what comes next. The Firing Line has to understand that landing a BS 180 kickflip on flatground puts you in switch, so the next trick in the line should be a switch trick like a switch kickflip, not a random regular-stance one. Skaters will get it 😉. That's the right balance.

The pieces I'd recommend without reservation are expo-sqlite for any local persistence past "a few key-value pairs", EAS Update for shipping JS-only fixes without a store re-review, and Reanimated 4 for any animation that would feel cheap on the JS thread. The pieces I'd think harder about on a bigger app are the React Compiler (still flagged experimental), AsyncStorage as the catch-all for small state (it's fine, but MMKV is faster if you're storing a lot of small values), and the Leaflet-plus-Overpass map setup 🗺. The map is the part of Sketchy I'm least happy with and it's flagged beta in the app for that reason. It works (kinda), it's free, and it's the right call for now, but the plan is to figure out Google Maps cost-control once the app starts paying for that.

If you've been holding off on a mobile side project because mobile feels like a lot to learn from scratch, the gap between "I have an idea" and "this is on both stores" is smaller than it looks today. Initialise an Expo SDK 55 project, point it at EAS, and you'll be further along by the end of the week than you'd guess.