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.