0.6.1

Fixed

In-app messages now render what the builder shows. Everything below was
something an author could do in the dashboard, see in the preview, publish, and
have end users receive as nothing at all or as something else.

• Sections rendered empty. Puck stores a section's children under
  zones["<id>:content"], and this SDK read props.children, which Puck never
  writes. Every section was an empty box and everything inside it was lost.

• A deep link in a call to action did nothing. Button URLs were checked
  against an http/https allowlist, so myapp://order/4821, the most natural
  CTA in an in-app message on a deep linking platform, was refused before the
  host app's own handler was called. The check is now the denylist the platform
  itself uses, so any scheme but the ones that can run code will open.

• An authored zero was thrown away. borderRadius: 0, padding: 0 and the
  rest were replaced by the default, and every stock template ships
  borderRadius: 0 on its images, so their corners were rounded anyway.

• Image sizes were read wrongly. The width and height fields are free text
  whose own labels offer "auto", "200" and "200px". Height was not applied at
  all here, and a width of "auto" became the invalid "autopx".

• Button styles were ignored. Outline and soft buttons rendered as solid
  blocks. Since the text colour is labelled "filled only", authors leave it
  white, so those arrived as white on light: an invisible call to action. Emoji
  was dropped, a button that was not full width stretched anyway, and an action
  of "close" navigated instead of dismissing.

• Markdown links were shown as brackets and a raw URL, though the field
  label promises them and the preview drew them.

• The message surface was ignored. Background colour, gradient, image,
  padding, width and vertical alignment were all authored and none applied, so
  a message designed on a gradient arrived as a plain white card.

• AppIcon, StoreButtons and DeepLinkButton rendered nothing. They describe
  the app rather than the message, and the API now sends that context with the
  messages, so all three draw.

• A message with only a title and body showed an empty card. Both are now
  rendered when there is no designed content.

• Spacing matches the other renderers, so a message is the height it was
  designed to be.

• On React Native itself: every URL check said no. This package read
  new URL(x).protocol. React Native installs its own URL over the global one,
  and for most of the versions supported here its getters are stubs that throw
  (protocol, hostname, host and origin are all "is not implemented" in
  0.73 and gained real bodies only much later). Every call sat inside a try, so
  the throw read as "unparseable" and the answer was always no.

  On a device that meant no image in any message, every button inert, every
  markdown link shown as brackets and a raw URL, and the app icon permanently a
  placeholder. It also reached beyond messages: Links.resolve read origin
  outside its try, so short link resolution threw despite being documented never
  to throw, and trackLinkOpen did the same in a call the docs show being made
  without awaiting it. Both have been failing this way since 0.6.0 for anyone on
  an older React Native.

  Schemes are parsed here now rather than asked of the platform, and the tests
  run against the URL React Native actually ships, since running them on Node's
  is what let this pass unnoticed.

• A section whose zone names itself recursed until the app was killed, with no
  error and nothing on screen. Nesting is capped, a malformed component is
  skipped rather than allowed to throw mid render, and a colour React Native
  cannot parse falls back instead of taking the element with it.

Added

• MessageAppContext, the app a message belongs to, as returned alongside
  /v1/api/messages.
• MessageContent.zones, which was missing from the type entirely.

Fixed

• An image in an in-app message vanished when its height was set in the
  dashboard.

  The builder's width and height are free text, and the field itself offers
  "auto", "200" and "200px" as examples. React Native takes a number or a
  percentage and nothing else: it lays out a view given anything else at zero,
  which for an image means it renders and cannot be seen, with the text and
  buttons around it looking perfectly fine. Width was already read this way;
  height was cast straight to a number, so typing a height into the field, the
  one thing the field is for, lost the image.

  Both are now read the same way and always resolve to something React Native
  can lay out. A height of "auto" falls back to 200, because an image that has
  not been measured cannot be sized from nothing, and the fallback at least
  renders.

0.6.0

Added

• Tolinku.links.resolve(url) turns a link the operating system handed the app
  into the route and token it means.

  An app receives the URL that was tapped, exactly as written. That is fine
  while the URL is readable: /order/4821 says "order" and the app can route
  it. A short link is the same route written as a code, /s7k2p9q/4821, and
  nothing in it says "order", nor can the code be worked out on the device. An
  app parsing the path itself sees a first segment it has never heard of and
  does nothing, so the link opens the app and then appears to fail: no error, no
  screen, no clue. Short links are what the dashboard offers for sharing and
  what a QR code carries, so this is not a rare path.

  const link = await Tolinku.links.resolve(url);
  if (link) route(link.deep_link_path); // "/order/4821/receipt"

  A readable URL comes back unchanged, so an app can resolve everything rather
  than guessing which kind it has. The question goes to the link's own host,
  which is how the platform knows the Appspace, so a link on someone else's
  domain answers nothing. Never throws: this runs during a cold start, and an
  exception there is the difference between a link that did not route and an app
  that did not start.

  Needs a platform new enough to answer for a whole path on /v1/api/path.

Fixed

• Referral links shared in short form could open the app without the referral
  code reaching it. Resolve incoming links with Tolinku.links.resolve and the code arrives
  with the rest of the link.

v0.5.0

Added

trackLinkOpen(url) reports a link that opened the app without the browser being
involved. A Universal Link or App Link hands the app the URL directly, so Tolinku
is never contacted and the tap is not counted. The taps that go missing are the
ones from people who already have the app, so a campaign aimed at existing
customers reads as a failure exactly when it worked.

Call it wherever the app receives a link. Both arrivals need it: a link that
launches the app cold arrives somewhere different from one tapped while it is
already running. Wiring both is safe, since the same link inside a few seconds is
reported once.

claimBySignals accepts the signals as parameters on every SDK, overriding what
the device reports. iOS and Android previously took none.

Fixed

A blank override no longer discards the value the device reported. An unset
configuration value and a failed lookup both arrive that way, and matching counts
a signal that is present and disagrees while skipping one that is absent, so
sending the blank made the match worse rather than leaving it alone.

One rule now decides what a link may open, in every SDK. Android matched a
prefix, so it refused HTTPS:// in capitals, which the other four opened.

v0.4.0

Added

• Tolinku.configure() initialises the SDK. The name the Android, iOS and
  Flutter SDKs use. Tolinku.init() does the same thing and still works; it is
  what this package shipped and breaking it would serve nobody. It is meant for
  deprecation later, once moving off it is a one-line change rather than a
  surprise.

  Teardown needed nothing here: this SDK already called it destroy(), which is
  now the name on all five.

Added

• claimDeferredLink() recovers the link that led to an install, asking the Play
  Install Referrer first and falling back to device signal matching. Call it once
  on first launch instead of choosing between claimByToken and claimBySignals
  yourself.

• The Play Install Referrer is read by this package directly, so nothing extra
  needs installing. Android links already carried a referrer token to the store
  and nothing read it back, which left every install matched only by device
  signals: probabilistic, and expiring two hours after the click.

  Autolinking is per-platform, so an iOS-only app never builds it, and
  NativeModules is read lazily so its absence in Expo Go degrades to signal
  matching rather than crashing.

• claimDeferredLink() runs once per install and remembers it, so calling it on
  every launch costs nothing after the first. A dropped request is not counted as
  an answer, so a first launch without a connection retries rather than spending
  the install's one chance at attribution.

• Token claims now name their Appspace. It narrows what a token may claim, never
  widens it, and it is what lets a failed claim be counted: the default host
  resolves to no Appspace, so a miss previously belonged to nobody and the
  reported referrer match rate would have read 100% regardless.

Fixed

• Tolinku.VERSION and the User-Agent reported 0.1.0 through two releases.
  A test now fails if the constant drifts from the published version.

v0.3.0

Fixed

• Deferred deep link signal matching. The signals sent for claimBySignals did not
  match the values recorded by the landing page, so some of them could never contribute
  to a match. See the per-SDK notes below.

• claimBySignals no longer reports a configuration error as a plain "no match". A 403
  (wrong appspaceId) is now surfaced with an explanation instead of being swallowed.

  Note appspaceId is your Appspace ID, copied from the dashboard under Settings. It is
  not your subdomain or slug. Sending the slug was the cause of the report behind this
  release, and now produces an explicit error rather than a silent null.

• The language signal defaulted to a bare en rather than the device locale, so it
  rarely matched. Now derives the full locale tag from Intl when not supplied.

• Matching now also compares device pixel ratio and OS version, and reports them
  automatically where the platform exposes them.

v0.2.0

Add ecommerce analytics module with 13 event types, cart ID lifecycle, and updated dependencies.

v0.1.0

Initial Release

The official Tolinku SDK for React Native and Expo.

Features

• Deep Linking: Deferred deep link claiming (by token and device signals)
• Analytics: Event tracking with automatic batching
• Referrals: Create, complete, milestone tracking, leaderboard, and reward claiming
• In-App Messages: Targeted messages with React Native modal rendering

Install

npm install @tolinku/react-native-sdk

Links

• Documentation
• GitHub