You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
ns embed ios (added in #5803) leaves the host project's metadata setup half-finished. This issue tracks the follow-ups.
Context: NativeScript/ios#488 changes the runtime so that, when Config.MetadataPtr is nil, it reads the __DATA,__TNSMetadata section of the host executable. Until that lands, the section ns embed ios links into the host is never read (embedded apps run on the default metadata baked into NativeScript.framework), which is why these problems have gone unnoticed. Once it lands, the section becomes the metadata the embedded app actually runs on.
project.addToOtherLinkerFlags('-sectcreate __DATA __TNSMetadata "<project>/metadata-arm64.bin"') runs on every ns embed ios: embed forces prepareProject each time (prepare-native-platform-service.ts), and addToOtherLinkerFlags in nativescript-dev-xcode pushes without checking for an existing entry. The host's OTHER_LDFLAGS gains one more copy per run.
ld accepts a repeated -sectcreate for the same segment/section and concatenates the files (checked with a two-flag test link: a 17-byte file produced a 34-byte section). So every re-run adds another full copy of the metadata (roughly 9–12 MB each) to the host executable. The app still works, because the runtime reads from the start of the section.
2. Nothing delivers the metadata file
The flag points at <hostProject>/<projectName>/metadata-arm64.bin, but nothing creates that file. The "Copy Metadata (DEBUG)" build phase is commented out and step 2 ("Ensure metadata is copied as a file") is a // TODO. ns embed is a prepare, so the metadata generator never runs. Users have to build the NativeScript project separately and copy the file by hand (as the ns-embed-example README describes), and the host fails to link if it is missing.
3. The architecture and SDK are hardcoded
The flag always names metadata-arm64.bin, and the documented manual step copies the simulator build's file, so device builds link metadata generated against the simulator SDK. The app template uses metadata-$(CURRENT_ARCH).bin from the configuration build dir.
4. Failures in this block are silent
The whole host-project setup is wrapped in a try/catch that only logs at trace level ("Error adding NativeScript group to host project"), so a failure leaves the host partially configured with no visible error.
Describe the solution you'd like
Make adding the -sectcreate flag idempotent (skip or replace an existing entry), and clean up duplicates left by earlier runs.
Have ns embed ios put the metadata in place, e.g. a build phase in the host that copies it from the NativeScript project's build output (what the commented-out phase sketched).
Reference the metadata per architecture and SDK instead of a fixed metadata-arm64.bin.
Surface errors from the host-project setup instead of logging them at trace level.
Describe alternatives you've considered
For the metadata file: instead of copying the NativeScript project's metadata, run the metadata generator against the host project's own build settings (the nsld.sh mechanism the app template uses). That would also cover native classes that exist only in the host, which the copied metadata does not describe, but it is a larger change. Copying is a reasonable first step.
Having the host pass Config.MetadataPtr explicitly is no longer needed once NativeScript/ios#488 is in: the runtime finds the host executable's section itself, so Swift hosts need no C shim.
Related docs change outside this repo: NativeScript/ns-embed-example tells hosts to add NativeScriptSDK. Hosts set up with ns embed link their own metadata and should add the NativeScript product instead, otherwise they also carry the unused 8.8 MB default-metadata framework.
Is your feature request related to a problem? Please describe.
ns embed ios(added in #5803) leaves the host project's metadata setup half-finished. This issue tracks the follow-ups.Context: NativeScript/ios#488 changes the runtime so that, when
Config.MetadataPtris nil, it reads the__DATA,__TNSMetadatasection of the host executable. Until that lands, the sectionns embed ioslinks into the host is never read (embedded apps run on the default metadata baked intoNativeScript.framework), which is why these problems have gone unnoticed. Once it lands, the section becomes the metadata the embedded app actually runs on.The relevant block is in
lib/services/ios-project-service.ts.1. The linker flag is appended on every run (bug)
project.addToOtherLinkerFlags('-sectcreate __DATA __TNSMetadata "<project>/metadata-arm64.bin"')runs on everyns embed ios: embed forcesprepareProjecteach time (prepare-native-platform-service.ts), andaddToOtherLinkerFlagsinnativescript-dev-xcodepushes without checking for an existing entry. The host'sOTHER_LDFLAGSgains one more copy per run.ldaccepts a repeated-sectcreatefor the same segment/section and concatenates the files (checked with a two-flag test link: a 17-byte file produced a 34-byte section). So every re-run adds another full copy of the metadata (roughly 9–12 MB each) to the host executable. The app still works, because the runtime reads from the start of the section.2. Nothing delivers the metadata file
The flag points at
<hostProject>/<projectName>/metadata-arm64.bin, but nothing creates that file. The "Copy Metadata (DEBUG)" build phase is commented out and step 2 ("Ensure metadata is copied as a file") is a// TODO.ns embedis a prepare, so the metadata generator never runs. Users have to build the NativeScript project separately and copy the file by hand (as thens-embed-exampleREADME describes), and the host fails to link if it is missing.3. The architecture and SDK are hardcoded
The flag always names
metadata-arm64.bin, and the documented manual step copies the simulator build's file, so device builds link metadata generated against the simulator SDK. The app template usesmetadata-$(CURRENT_ARCH).binfrom the configuration build dir.4. Failures in this block are silent
The whole host-project setup is wrapped in a
try/catchthat only logs at trace level ("Error adding NativeScript group to host project"), so a failure leaves the host partially configured with no visible error.Describe the solution you'd like
-sectcreateflag idempotent (skip or replace an existing entry), and clean up duplicates left by earlier runs.ns embed iosput the metadata in place, e.g. a build phase in the host that copies it from the NativeScript project's build output (what the commented-out phase sketched).metadata-arm64.bin.Describe alternatives you've considered
For the metadata file: instead of copying the NativeScript project's metadata, run the metadata generator against the host project's own build settings (the
nsld.shmechanism the app template uses). That would also cover native classes that exist only in the host, which the copied metadata does not describe, but it is a larger change. Copying is a reasonable first step.Having the host pass
Config.MetadataPtrexplicitly is no longer needed once NativeScript/ios#488 is in: the runtime finds the host executable's section itself, so Swift hosts need no C shim.Anything else?
NativeScriptSDKSwiftPM product additionally embeds a default-metadata framework for zero-config hosts, while theNativeScriptproduct stays lean.NativeScript/ns-embed-exampletells hosts to addNativeScriptSDK. Hosts set up withns embedlink their own metadata and should add theNativeScriptproduct instead, otherwise they also carry the unused 8.8 MB default-metadata framework.Please accept these terms