RORK LABJP
BUILD — Rork Max runs real Macs in the cloud loaded with Xcode and the iOS SDK, writing SwiftUI, compiling, reading the errors and building again. That loop, not the code generation, is what lifts the outputNATIVE — What comes out is pure Swift and SwiftUI, not React Native. Reaching AR, Metal graphics and widgets that React Native cannot touch is the real gap between this and other buildersPLATFORMS — Coverage spans iPhone, iPad, Apple Watch, Apple TV and Vision Pro, plus iMessage. Worth a look if you want to start from a watch app or an extension rather than a phone screenCOMPANION — The Rork Companion app lets you check a generated build on a real iPhone without a paid Apple Developer account, lowering the bar for trying a first project end to endPRICING — Free to start, paid plans from $25 a month, and Rork Max on the $200 Max plan. Worth working out up front how many projects it takes to earn that backDEADLINE — From August 31, 2026, Google Play requires target API level 36 or higher for new apps and updates alike. Ten days out, and the targetSdkVersion of what you generate is yours to verifyBUILD — Rork Max runs real Macs in the cloud loaded with Xcode and the iOS SDK, writing SwiftUI, compiling, reading the errors and building again. That loop, not the code generation, is what lifts the outputNATIVE — What comes out is pure Swift and SwiftUI, not React Native. Reaching AR, Metal graphics and widgets that React Native cannot touch is the real gap between this and other buildersPLATFORMS — Coverage spans iPhone, iPad, Apple Watch, Apple TV and Vision Pro, plus iMessage. Worth a look if you want to start from a watch app or an extension rather than a phone screenCOMPANION — The Rork Companion app lets you check a generated build on a real iPhone without a paid Apple Developer account, lowering the bar for trying a first project end to endPRICING — Free to start, paid plans from $25 a month, and Rork Max on the $200 Max plan. Worth working out up front how many projects it takes to earn that backDEADLINE — From August 31, 2026, Google Play requires target API level 36 or higher for new apps and updates alike. Ten days out, and the targetSdkVersion of what you generate is yours to verify
Articles/Dev Tools
Dev Tools/2026-07-04Intermediate

Should You Show a Read More Link? Let the Rendered Text Decide in Rork (Expo)

Clamping a product description to three lines and adding a Read more toggle sounds simple, until the toggle also appears under single-line text. This walks through measuring the real line count with onTextLayout so the toggle only shows when text actually overflows, covering iOS vs Android quirks, expand animation, and font scaling.

Rork539Expo175React Native227Text UIindie developer39

Premium Article

You add a Read more link under a product description, and then it shows up under a one-line blurb too. Building a wallpaper app on my own, I hit exactly this awkwardness on the detail screen and stopped to fix it properly. Long copy should collapse; short copy needs no toggle at all. The decision to show it or not should come from the number of lines that actually rendered, not from an unreliable proxy like character count. That is what this piece is about.

In React Native, which is the foundation the standard apps Rork generates sit on top of, a Text component will clamp and add an ellipsis when you set numberOfLines. What it will not do is tell you whether clamping happened. To show the toggle correctly, you have to measure whether the rendered body truly exceeds the line limit yourself.

Character counts always break somewhere

The first instinct is a threshold: show the toggle when the body passes 120 characters. It is easy, and it drifts almost immediately. Japanese and English fit wildly different amounts of text per line, and emoji, URLs, and line breaks all move the count. The same 100 characters land in two lines on a wide device and four lines on a small iPhone. Character count guarantees nothing about how many lines appear on screen.

I once shipped the threshold approach. It looked fine in Japanese, then the moment I switched to an English locale a wave of empty toggles appeared under short text. Moving the basis of the decision from input length to the rendered result looked like the long way around, but it was the reliable one.

Read the rendered line count with onTextLayout

React Native's Text has an onTextLayout callback. After the text is laid out, it hands you an array with information about each line. The line count is simply the length of that array.

The crucial detail: do not attach numberOfLines while measuring. If you do, the layout result is rounded to that limit, and you cannot tell whether the text was five lines clamped to three or genuinely three lines. So you measure once with no limit, look at the result, and decide whether the toggle is needed.

import { useState, useCallback } from 'react';
import { Text, Pressable, View, type TextLayoutEventData, type NativeSyntheticEvent } from 'react-native';
 
const COLLAPSED_LINES = 3;
 
type Props = { children: string };
 
export function ExpandableText({ children }: Props) {
  // needsToggle: does the body exceed 3 lines?
  // measured: have we measured once already?
  const [needsToggle, setNeedsToggle] = useState(false);
  const [measured, setMeasured] = useState(false);
  const [expanded, setExpanded] = useState(false);
 
  const onTextLayout = useCallback(
    (e: NativeSyntheticEvent<TextLayoutEventData>) => {
      if (measured) return; // ignore re-layouts after expanding
      const lineCount = e.nativeEvent.lines.length;
      setNeedsToggle(lineCount > COLLAPSED_LINES);
      setMeasured(true);
    },
    [measured],
  );
 
  return (
    <View>
      {/* Measurement pass: render once off-screen with no limit to get the count */}
      {!measured && (
        <Text
          onTextLayout={onTextLayout}
          style={{ position: 'absolute', opacity: 0, left: 0, right: 0 }}
          accessibilityElementsHidden
          importantForAccessibility="no-hide-descendants"
        >
          {children}
        </Text>
      )}
 
      {/* Display pass: clamp with numberOfLines only when collapsed */}
      <Text numberOfLines={expanded ? undefined : COLLAPSED_LINES}>
        {children}
      </Text>
 
      {needsToggle && (
        <Pressable
          onPress={() => setExpanded((v) => !v)}
          hitSlop={8}
          accessibilityRole="button"
          accessibilityLabel={expanded ? 'Collapse text' : 'Read more'}
        >
          <Text style={{ color: '#2563eb', marginTop: 4 }}>
            {expanded ? 'Show less' : 'Read more'}
          </Text>
        </Pressable>
      )}
    </View>
  );
}

The measurement Text is placed off-screen with absolute positioning and zero opacity, rendered once, then removed as soon as the count is known. The display Text applies numberOfLines only while collapsed. This two-layer approach lets you know whether clamping occurred while keeping flicker to a minimum. Always hide the measurement element from screen readers, or the reader will pick up the body twice.

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
Measure the real rendered line count with onTextLayout and show Read more only when the body exceeds three lines, with working code you can drop in
Avoid the trap where measuring with numberOfLines still attached always rounds down to three lines, and learn why iOS and Android disagree on the count
See why the expand/collapse LayoutAnimation silently does nothing on Android, plus a toggle design that respects VoiceOver and 200% text size
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.

or
Unlock all articles with Membership →
Share

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.

  • Copy-paste ready implementation code
  • New advanced guides published daily
  • $5/mo or $10 for lifetime access
View Membership →

Related Articles

Dev Tools2026-07-30
What Renovate may bump in an Expo app, and what it must never touch
Turning on automated dependency updates in a Rork-generated app also hands Renovate the 123 packages Expo SDK 57 pins. Measured on 2026-07-30, six of them sit a full major version behind npm latest. Here is how to generate the ignore list from the SDK instead of maintaining it by hand.
Dev Tools2026-07-28
Counting what prebuild --clean will erase before you upgrade to Expo SDK 57
A raw diff between two generated ios/ trees showed 649 changed lines; only 3 were real edits. How to count what prebuild --clean erases, and move it into a config plugin.
Dev Tools2026-07-27
When to Raise Your Minimum iOS Version — Count Leftover Branches, Not User Percentages
Judging a minimum OS bump by usage share produces the same answer every year, so the decision never happens. Here is the annotation convention, the sweep script that counts how many branches each candidate floor would retire, and what to watch for 30 days after.
📚RECOMMENDED BOOKS
Build a Large Language Model (From Scratch)
Sebastian Raschka
LLM Dev
Prompt Engineering for LLMs
Berryman & Ziegler
Prompting
AI Engineering
Chip Huyen
AI Eng
* Contains affiliate links
See all →