NativeScript iOS Daily: Worker Startup Lifecycle Fixes

A single merged pull request, number 473, closes out three related failure paths that could leave worker threads, isolates, or memory dangling when a worker fails during startup. All three fixes trace back to the same root issue: cleanup and registry timing that assumed a worker's startup always succeeds.

Duration: PT2M11S

Episode overview

This episode is a short developer briefing from NativeScript iOS Daily.

It explains recent repository work in plain language.

  • Show: NativeScript iOS Daily
  • Published: 2026-09-11T13:15:26Z
  • Audio duration: PT2M11S

Transcript excerpt

This excerpt keeps the crawler page concise. Listen to the episode or use the RSS feed for the full update.

Good morning. It's September 11th, 2026, and today's briefing centers on one pull request that quietly closes a set of dangerous edge cases in the worker lifecycle.

The headline: workers that fail during startup were not dying cleanly. PR 473, from Adrian Niculescu, fixes three separate but related problems, all stemming from the same assumption — that a worker's startup path always finishes normally.

First, a worker whose entry script doesn't exist used to report the error and then just keep running. The thread and its isolate stayed alive indefinitely unless the parent explicitly called terminate. Now it terminates itself right after reporting, matching the behavior already used when a worker's entry script…

Second, there was a registry ordering bug. The worker's registry entry was only published after startup was already queued, because the id was assigned late. If a worker closed itself or ran out of heap immediately, its runtime could be deleted before the registry entry existed — leading to a null dereference during…

Third, and most subtle: error reports sent to the parent's onerror handler were posted as a deferred task that read the wrapper's isolate and persistent handle…

The…

Nearby episodes from NativeScript iOS Daily

  1. tvOS Gets a Runtime Overhaul
  2. Worker Startup Cleanup
  3. Worker Overhaul and a Suspended-App Crash Fix
  4. Worker API Gets a Redesign, Plus a Suspend-State Crash Fix
  5. Runtime Startup Crash Fixes
  6. Closing the Worker Memory-Corruption Hunt
  7. Worker Threads Land, Then Get Hardened
  8. Web Globals Land, Memory Leaks Get Squashed