---
url: https://nsh.dev/hi/docs
description: "Native Shell क्या है: iOS, Android, macOS, Windows, Linux और वेब के लिए एक Rust-first नेटिव UI फ़्रेमवर्क, जिसमें हर प्लैटफ़ॉर्म का अपना UI और इंटरैक्शन होता है।"
---

# परिचय

Native Shell (संक्षेप में NSH) हर प्लेटफ़ॉर्म के लिए एक नेटिव UI फ़्रेमवर्क है। आप ऐप को एक बार, एक ही ऐप मॉडल के साथ बनाते हैं: कंपोनेंट, सिग्नल, स्टाइल और हर जगह वही API। NSH उसे **iOS, Android, macOS, Windows, Linux और वेब** पर चलाता है, और हर बार वह उस प्लेटफ़ॉर्म के अपने ऐप की तरह चलता है: उसी प्लेटफ़ॉर्म के अपने व्यू से बना, उसी के अपने टेक्स्ट सिस्टम से एडिट होने वाला, और वैसे इस्तेमाल होने वाला जैसी उसके यूज़र्स को उम्मीद होती है। पूरा ऐप **Rust** में लिखें, स्क्रीन **TSX** में लिखें, या दोनों को एक ही इंजन पर मिलाएँ। उसी इंजन के ऊपर, आपके शिप किए हुए ऐप रन टाइम पर नया UI ले सकते हैं, जो आपकी टीम ने लिखा हो या किसी मॉडल ने जनरेट किया हो, साइन किए गए मॉड्यूल के रूप में और होस्ट द्वारा कॉन्फ़िगर किए गए सैंडबॉक्स में।

> [!IMPORTANT]
> NSH नेटिव व्यू और इंटरैक्शन देता है; विज़ुअल डिज़ाइन ऐप का अपना होता है। कंपोनेंट, स्टेट और API सभी प्लेटफ़ॉर्म पर साझा हैं, जबकि रंग, टाइपोग्राफ़ी, स्पेसिंग और आकार ऐप से आते हैं। टेक्स्ट इनपुट, फ़ोकस और मेन्यू हर डिवाइस की इंटरैक्शन परंपराओं का पालन करते हैं। देखें [लक्ष्य और डिज़ाइन सिद्धांत](https://nsh.dev/translations/hi/docs/goals.md)।

<a id="what-native-means"></a>

## नेटिव का मतलब

NSH में नेटिव की दो परतें हैं: प्लेटफ़ॉर्म की बुनियाद, और प्लेटफ़ॉर्म का इंटरैक्शन।

**प्लेटफ़ॉर्म की बुनियाद।** हर प्लेटफ़ॉर्म का अपना एक बैकएंड है, जो उस प्लेटफ़ॉर्म के पहले से मौजूद UI पर बना है:

| प्लेटफ़ॉर्म | व्यू | टेक्स्ट | टेक्स्ट इनपुट |
|---|---|---|---|
| iOS | UIKit | CoreText | सिस्टम के टेक्स्ट फ़ील्ड और टेक्स्ट व्यू |
| Android | Android views | `StaticLayout` | `EditText` |
| macOS | AppKit, Core Animation | CoreText | `NSTextField`, `NSTextView` |
| Windows | Direct2D से ड्रॉ की गई Win32 विंडो | DirectWrite | NSH का एडिटर, सिस्टम के इनपुट मेथड (IMM32) के साथ |
| Linux | GTK 4 | Pango | GTK के `Text` और `TextView` |
| वेब | CSS से स्टाइल किए गए HTML एलिमेंट | ब्राउज़र के फ़ॉन्ट | ब्राउज़र के इनपुट |

टेक्स्ट सिलेक्शन और उसका मेन्यू, इनपुट मेथड, एक्सेसिबिलिटी और स्क्रॉलिंग प्लेटफ़ॉर्म से आते हैं, और नया OS रिलीज़ इनमें जो कुछ लाता है, वह ऐप तक अपने-आप पहुँच जाता है। नेटिव कंपोनेंट, जैसे मैप, वेब व्यू, वीडियो प्लेयर या होस्ट द्वारा रजिस्टर किया गया कोई भी व्यू, उसी हायरार्की में एक और व्यू होते हैं, जिन्हें बाकी व्यू के साथ ही लेआउट, क्लिप और स्क्रॉल किया जाता है ([नेटिव कंपोनेंट](https://nsh.dev/translations/hi/docs/native-components.md))।

**प्लेटफ़ॉर्म का इंटरैक्शन।** NSH जो कंपोनेंट [`nsh/base`](https://nsh.dev/translations/hi/modules/nsh-base.md) में देता है, वे वैसे ही व्यवहार करते हैं जैसा हर डिवाइस के यूज़र्स को उम्मीद होती है, इसलिए ऐप को उन्हें सिर्फ़ एक बार लिखना होता है:

| | डेस्कटॉप (और डेस्कटॉप ब्राउज़र) | फ़ोन और टैबलेट |
|---|---|---|
| `Menu` | ट्रिगर पर एक पॉपअप; सबमेन्यू अपने आइटम के बगल में कैस्केड होते हैं | नीचे से आने वाली शीट; सबमेन्यू अपने मेन्यू के आइटम की जगह ले लेता है |
| `ContextMenu` | पॉइंटर पर राइट क्लिक करने से खुलता है | ट्रिगर पर उंगली टिकाए रखने से शीट के रूप में खुलता है |
| `Tooltip` | पॉइंटर के ट्रिगर पर ठहरने पर दिखता है | ऐप के खोलने पर दिखता है |
| `Popover` | बाहर प्रेस करने पर बंद हो जाता है और प्रेस पॉइंटर के नीचे की चीज़ तक पहुँचता है | बाहर प्रेस करने पर बंद हो जाता है |

पेज, डायलॉग, कीबोर्ड और स्टेटस बार भी इसी विचार पर चलते हैं: नेविगेशन स्टैक हर प्लेटफ़ॉर्म की अपनी गति के साथ पुश और पॉप होते हैं, और बैक बटन, Escape और स्वाइप-बैक वही करते हैं जो वहाँ करते हैं ([नेविगेशन](https://nsh.dev/translations/hi/docs/navigation.md))।

<a id="from-phone-to-desktop-to-web"></a>

## फ़ोन से डेस्कटॉप और वेब तक

NSH में क्रॉस-प्लेटफ़ॉर्म का मतलब है कि हर डिवाइस को वह ऐप मिलता है जिसकी वह उम्मीद करता है, न कि वही स्क्रीन छोटी या बड़ी करके:

- **एक ऐप मॉडल।** ऐप के कंपोनेंट, स्टेट, बिज़नेस लॉजिक और स्क्रीन साझा हैं; हर बैकएंड उन्हें अपने प्लेटफ़ॉर्म से मैप करता है।
- **आकार बदलने वाले लेआउट।** Flexbox और CSS grid को हर प्लेटफ़ॉर्म पर [Taffy](https://github.com/DioxusLabs/taffy) लेआउट करता है, और Tailwind के ब्रेकपॉइंट (`md:`, `lg:`) और विंडो का आकार (Rust में `window()`) सिर्फ़ साइज़ नहीं, बल्कि संरचना बदलते हैं: एक चैट ऐप चौड़ी विंडो में साइडबार, बातचीत और संदेश साथ-साथ दिखाता है, और फ़ोन पर एक बार में एक स्क्रीन ([लेआउट](https://nsh.dev/translations/hi/docs/layout.md), [Tailwind](https://nsh.dev/translations/hi/docs/tailwind.md))।
- **हर डिवाइस का अपेक्षित इनपुट।** डेस्कटॉप पर पॉइंटर, होवर, राइट क्लिक, शॉर्टकट और फ़ोकस; फ़ोन पर टच, जेस्चर, सॉफ़्टवेयर कीबोर्ड और पेज नेविगेशन। जहाँ ऐप को हर प्लेटफ़ॉर्म के लिए कुछ अपना चाहिए, वहाँ `desktop={{…}}` प्रॉप्स और `platform.select` यही बताते हैं ([प्लेटफ़ॉर्म-विशिष्ट कोड](https://nsh.dev/translations/hi/docs/platform-specific.md))।
- **हर टारगेट पर जाँचा हुआ।** `nsh test` ऐप के टेस्ट हेडलेस चलाता है, और वही टेस्ट macOS, Windows, Linux और GPUI विंडो, iOS सिमुलेटर, Android डिवाइस या ब्राउज़र में, प्लेटफ़ॉर्म के अपने इनपुट के साथ चलाता है ([टेस्टिंग और ट्रेसिंग](https://nsh.dev/translations/hi/docs/testing-and-trace.md))।

एक चैट क्लाइंट जैसे ऐप को लें। उसका डेवलपर उसे डेस्कटॉप पर `nsh run` से बनाता है, फ़ोन का लेआउट जाँचने के लिए उसे `nsh run --target ios` से iOS सिमुलेटर में खोलता है, फिर `nsh run --target web` से ब्राउज़र में, हर बार वही प्रोजेक्ट, और `nsh package` इंस्टॉल होने वाले ऐप और वेबसाइट बनाता है। जो काम पहले हर प्लेटफ़ॉर्म के लिए एक पूरी टीम लेती थी, उसे एक इंजीनियर संभाल सकता है, जबकि बैकएंड साथ-साथ बनता रहता है।

<a id="rust-first"></a>

## पहले Rust

NSH Rust में बना है, और Rust इसके साथ ऐप लिखने के लिए एक फ़र्स्ट-क्लास भाषा है:

- **पूरे ऐप Rust में।** UI, लॉजिक और कंपोनेंट Rust में होते हैं, जो हर प्लेटफ़ॉर्म पर नेटिव कोड में कंपाइल होते हैं, और Rust के ओनरशिप, टाइप, थ्रेड और crates.io इकोसिस्टम के साथ आते हैं। कंप्यूटेशन नेटिव स्पीड पर चलता है, और बड़ा डेटा, पार्सिंग और सिस्टम का काम उस भाषा में रहता है जो उनके लिए सबसे उपयुक्त है ([Rust के साथ बनाना](https://nsh.dev/translations/hi/docs/rust.md))।
- **दूसरा रास्ता TSX।** TSX तेज़ी से लिखी जाने वाली स्क्रीन, प्लगइन, छोटे ऐप और रन टाइम पर पहुँचाए जाने वाले UI के लिए उपयुक्त है। यह Rust वाले इंजन पर ही चलता है, उन्हीं प्रिमिटिव, बेस कंपोनेंट और सिग्नल के साथ।
- **दोनों साथ।** एक Rust ऐप TSX स्क्रीन ले सकता है, और TSX स्क्रीन ऐप के Rust कंपोनेंट, मॉड्यूल और क्लास इम्पोर्ट करती हैं।
- **एक टूलचेन।** एक अकेला `nsh` एक्ज़ीक्यूटेबल हर टारगेट के लिए ऐप बनाता, बिल्ड करता, टाइप-चेक करता, हॉट रीलोड के साथ चलाता, टेस्ट करता, पैकेज करता और साइन करता है। यह अपना TSX बंडलर और TypeScript चेकर साथ लाता है, इसलिए Rust, Swift, Kotlin या C++ से आने वाला डेवलपर Rust और `nsh` इंस्टॉल करता है, और काम शुरू कर देता है ([इंस्टॉलेशन](https://nsh.dev/translations/hi/docs/installation.md), [CLI](https://nsh.dev/translations/hi/docs/cli.md))।

<a id="an-app"></a>

## एक ऐप

वही काउंटर, Rust और TSX में:

```rust
use nsh_core::prelude::*;

#[component]
pub fn Counter() -> impl IntoElement {
    let count = signal(0);
    view()
        .flex_1()
        .items_center()
        .justify_center()
        .gap_3()
        .child(text(move || count.get().to_string()).text_5xl().font_weight(FontWeight::BOLD))
        .child(
            view()
                .rounded_lg()
                .bg(rgb(0x2563eb))
                .px_5()
                .py_3()
                .active(|s| s.opacity(0.6))
                .on_press(move || count.update(|n| *n += 1))
                .child(text("Tap").text_lg().text_color(white())),
        )
}
```

```tsx
import { mount, signal, Text, View } from "nsh";

function Counter() {
  const count = signal(0);
  return (
    <View style={{ flex: 1, alignItems: "center", justifyContent: "center", gap: 12 }}>
      <Text style={{ fontSize: 48, fontWeight: "700" }}>{count()}</Text>
      <View
        onPress={() => count.update((n) => n + 1)}
        activeStyle={{ opacity: 0.6 }}
        class="rounded-lg bg-blue-600 px-5 py-3"
      >
        <Text class="text-white text-lg">Tap</Text>
      </View>
    </View>
  );
}

mount(Counter);
```

एक व्यू (`view()`, `<View>`) iOS पर `UIView` बन जाता है, Android पर `ViewGroup`, macOS पर `NSView`, Linux पर GTK विजेट, Windows पर Direct2D से ड्रॉ किया गया रिटेन्ड व्यू और वेब पर HTML एलिमेंट; टेक्स्ट एक नेटिव टेक्स्ट व्यू बन जाता है, और बटन का प्रेस फ़ीडबैक (`.active(..)`, `activeStyle`) मुख्य थ्रेड पर चलता है। जब आप टैप करते हैं, `count.update` एक सिग्नल बदलता है, और सिर्फ़ वही टेक्स्ट अपडेट होता है जो उसे पढ़ता है: कंपोनेंट फ़ंक्शन दोबारा नहीं चलता। Rust ऐप शुरू से अंत तक नेटिव कोड है; TSX ऐप में सिर्फ़ मॉड्यूल का अपना कोड JavaScript है।

<a id="retained-views"></a>

## रिटेन्ड व्यू

NSH रिटेन्ड है: हर एलिमेंट एक ऐसा व्यू है जिसे प्लेटफ़ॉर्म बनाए रखता है, और अपडेट सिर्फ़ उसे बदलता है जो बदला है।

- **सूक्ष्म-स्तरीय अपडेट।** Solid जैसे [सिग्नल](https://nsh.dev/translations/hi/docs/reactivity.md), जो नेटिव रूप से इम्प्लीमेंट किए गए हैं: कंपोनेंट एक बार चलते हैं, और बदलाव होने पर सिर्फ़ वे एक्सप्रेशन दोबारा चलते हैं जो बदले हुए सिग्नल को पढ़ते हैं।
- **सिर्फ़ जो बदला, वही थ्रेड पार करता है।** एक टर्न के बदलाव साथ में लेआउट किए जाते हैं और प्रति फ़्रेम व्यू ऑपरेशन के एक बैच के रूप में मुख्य थ्रेड को सौंपे जाते हैं; अपरिवर्तित स्टाइल और फ़्रेम नहीं भेजे जाते, और जिन व्यू को किसी ने नहीं छुआ वे जैसे हैं वैसे ही रहते हैं।
- **एनीमेशन नेटिव रूप से चलते हैं।** टाइमिंग, स्प्रिंग और डेके एनीमेशन, जेस्चर और स्क्रॉल से जुड़े मान प्लेटफ़ॉर्म की फ़्रेम क्लॉक पर कैलकुलेट होते हैं, प्रति फ़्रेम JS को कॉल किए बिना ([एनीमेशन](https://nsh.dev/translations/hi/docs/animation.md))।

यह उन स्क्रीन के लिए उपयुक्त है जिनसे ज़्यादातर ऐप बने होते हैं: चैट, मेल, फ़ॉर्म, लिस्ट, दस्तावेज़, सेटिंग, स्ट्रीम होकर आता AI जवाब, जहाँ एक बार में कुछ ही व्यू बदलते हैं और बाकी इंतज़ार करते हैं। ऐसी स्क्रीन अपडेट के बीच लगभग निष्क्रिय रहती हैं, और ProMotion डिस्प्ले पर स्क्रॉलिंग और एनीमेशन 120 FPS बनाए रखते हैं। [NSH परफ़ॉर्मेंस बेंचमार्क](https://github.com/longbridge/nsh-perf-bench) में, 500 पंक्तियों की एक कोट टेबल, जो प्रति सेकंड 1,000 बार अपडेट होती है, Linux पर NSH Rust में एक कोर का 18% इस्तेमाल करती है, जबकि [GPUI Fast](https://github.com/longbridge/gpui-fast) पर सीधे लिखी वही स्क्रीन 20% इस्तेमाल करती है। भारी कंप्यूटेशन Rust में होना चाहिए: TSX QuickJS में चलता है, जो एक इंटरप्रेटर है, जबकि Rust मॉड्यूल नेटिव स्पीड पर चलता है, भले ही उसे TSX कॉल करे; 100,000 पंक्तियों को सॉर्ट करने में इस तरह लगभग 3 ms लगते हैं, जितने साधारण Rust में लगते हैं ([परफ़ॉर्मेंस](https://nsh.dev/translations/hi/docs/performance.md))।

<a id="how-it-runs"></a>

## यह कैसे चलता है

टूलचेन एक अकेला `nsh` बाइनरी है। ऐप Rust में, TSX में, या दोनों में लिखा जाता है, और हर एक उसी Rust इंजन तक अपना अलग रास्ता लेता है।

<a id="rust-apps"></a>

### Rust ऐप

Rust ऐप एक क्रेट है, जो पूरी तरह Rust और Native से बनता है, बिना किसी JavaScript रनटाइम के:

1. **बिल्ड।** `nsh` हर टारगेट का रनर बनाता है, यानी iOS, Android, macOS, Windows, Linux या वेब ऐप, जिसमें आपका क्रेट लिंक होता है। कंपोनेंट, स्टेट, हैंडलर और इंजन एक साथ नेटिव कोड में कंपाइल होते हैं।
2. **रन।** ऐप का रूट कंपोनेंट इंजन थ्रेड पर Rust के रूप में चलता है। रनर में कोई JavaScript इंजन नहीं होता: किसी भी प्लेटफ़ॉर्म पर QuickJS Rust ऐप का हिस्सा नहीं है।

<a id="tsx-apps"></a>

### TSX ऐप

TSX ऐप (एक मॉड्यूल) `.tsx` / `.ts` फ़ाइलों का एक सेट है, जिसकी एक एंट्री होती है, आमतौर पर `App.tsx`:

1. **बिल्ड।** `nsh` मॉड्यूल की फ़ाइलों को (rolldown और Oxc के साथ) बंडल करता है और JSX को अपने कंपाइलर से कंपाइल करता है। `nsh` और `nsh/*` के इम्पोर्ट इम्पोर्ट ही रहते हैं: रनटाइम उन्हें नेटिव रूप से सर्व करता है, इसलिए बंडल में सिर्फ़ आपका कोड होता है। बंडल QuickJS बाइटकोड में कंपाइल होता है।
2. **रन।** इंजन थ्रेड बाइटकोड को [QuickJS](https://github.com/quickjs-ng/quickjs) में चलाता है, प्रति व्यू एक VM। कंपाइल किया गया JSX सीधे नेटिव रेंडरर को कॉल करता है, और JavaScript केवल UI का वर्णन करता है और इवेंट संभालता है; स्टाइल पार्स करना, Tailwind क्लास रिज़ॉल्व करना, डिफ़िंग, लेआउट और टेक्स्ट सब Rust में होता है।

<a id="the-difference"></a>

### अंतर

| | Rust ऐप | TSX ऐप |
|---|---|---|
| लिखा जाता है | Rust में | TSX (TypeScript और JSX) में |
| में बनता है | नेटिव कोड, जो हर टारगेट के रनर में लिंक होता है | QuickJS बाइटकोड, जिसे रनटाइम लोड करता है |
| JavaScript इंजन | कोई नहीं | QuickJS, प्रति व्यू एक VM |
| डेवलपमेंट के दौरान (`nsh run`) | हर सेव पर दोबारा बिल्ड और रीस्टार्ट | हर सेव पर हॉट अपडेट |
| रिलीज़ के बाद | ऐप के साथ शिप होता है | रन टाइम पर साइन किए गए पैकेज के रूप में, सैंडबॉक्स में भी पहुँचाया जा सकता है |
| उपयुक्त | पूरे ऐप, भारी कंप्यूटेशन, सिस्टम का काम | तेज़ी से लिखी जाने वाली स्क्रीन, प्लगइन, AI-जनरेटेड UI |

दोनों को मिलाया जा सकता है: एक Rust ऐप TSX स्क्रीन ले सकता है, और TSX स्क्रीन उसके Rust कंपोनेंट, मॉड्यूल और क्लास इम्पोर्ट करती हैं; ऐसा ऐप उन्हें चलाने के लिए QuickJS लिंक करता है ([Rust के साथ बनाना](https://nsh.dev/translations/hi/docs/rust.md))।

<a id="the-shared-engine"></a>

### साझा इंजन

इंजन से आगे, दोनों रास्ते एक ही हैं। बदलाव प्रति टर्न इकट्ठा किए जाते हैं, Taffy (flexbox और CSS grid) से लेआउट किए जाते हैं, और प्रति फ़्रेम व्यू ऑपरेशन के एक बैच के रूप में मुख्य थ्रेड को सौंपे जाते हैं; मुख्य थ्रेड उस बैच को नेटिव व्यू पर लागू करता है। टेक्स्ट को इंजन थ्रेड पर एक बार मापा और लेआउट किया जाता है (Apple प्लेटफ़ॉर्म पर CoreText, Android पर `StaticLayout`, Windows पर DirectWrite, Linux पर Pango, वेब पर ब्राउज़र के फ़ॉन्ट मेट्रिक्स) और मुख्य थ्रेड पर सिर्फ़ ड्रॉ किया जाता है।

वेब पर वही इंजन पेज के अंदर चलता है: ब्राउज़र CSS से स्टाइल किए गए HTML एलिमेंट दिखाता है, उन्हें स्क्रॉल करता है, उनका टेक्स्ट सिलेक्ट करता है और इनपुट संभालता है, और `nsh package --target web` ऐप को एक स्टैटिक साइट के रूप में प्रकाशित करता है, जिसकी फ़ाइलों के नाम उनकी सामग्री से तय होते हैं और जो किसी भी CDN के लिए तैयार है ([वेब](https://nsh.dev/translations/hi/docs/web.md))।

> [!NOTE]
> मुख्य थ्रेड कभी ऐप के कोड का इंतज़ार नहीं करता। सिस्टम जो सवाल सिंक्रोनस रूप से पूछता है (क्या यह इनपुट एक और अक्षर ले सकता है, क्या यूज़र स्वाइप-बैक कर सकता है, क्या यह शीट बंद हो सकती है), उनका जवाब पहले से सेट किए गए प्रॉप्स, जैसे `maxLength`, `popOnBack` या `closeOnSwipe`, से नेटिव रूप से दिया जाता है। इवेंट ऐप के हैंडलर तक बाद में पहुँचते हैं।
<a id="dynamic-ui-and-ai-generated-ui"></a>

## डायनामिक UI और AI-जनरेटेड UI

NSH की शुरुआत इस उद्देश्य से हुई थी कि नेटिव ऐप्स रिलीज़ के बाद भी UI ले सकें, और यह आज भी इसके मुख्य उपयोगों में से एक है। ऐप जहाँ भी कोई मॉड्यूल दिखाना हो, वहाँ `NshAppView` (iOS), `NshView` (Android), `AppView` (macOS, Windows, Linux और GPUI ऐप्स) या `createPlayer` (वेब पेज) एम्बेड करता है, और NSH उसके अंदर TSX मॉड्यूल चलाता है:

- **रिलीज़ के बाद डिलीवरी।** मॉड्यूल एक साइन किया हुआ पैकेज (`.nshpkg`) होता है, जिसे ऐप रन टाइम पर डाउनलोड करता है। उसे चलाने से पहले ऐप उसके सिग्नेचर को अपनी भरोसेमंद कुंजियों और एक रिवोकेशन सूची के विरुद्ध जाँचता है ([Signed packages](https://nsh.dev/translations/hi/docs/signed-packages.md))। होस्ट ऐप रनटाइम के साथ आता है; टीमें उसके API के विरुद्ध मॉड्यूल बनाती हैं और अपने समय-क्रम के अनुसार उन्हें डिलीवर करती हैं।
- **होस्ट का नियंत्रण बना रहता है।** हर मॉड्यूल अपने अलग QuickJS VM में चलता है, जिस पर मेमोरी, कॉल-टाइम और नोड की सीमाएँ लागू होती हैं, और वह केवल उन्हीं चीज़ों तक पहुँचता है जिनकी अनुमति होस्ट देता है: नेटवर्क होस्ट, वेब पेज, स्टेटस बार ([Sandbox and capabilities](https://nsh.dev/translations/hi/docs/sandbox-and-capabilities.md))। कई मॉड्यूल साथ-साथ चल सकते हैं।
- **यह ऐप के बाकी हिस्से जैसा दिखता है।** मॉड्यूल प्लेटफ़ॉर्म के अपने UI से रेंडर होते हैं, और होस्ट अपने नेटिव व्यू — जैसे मैप, प्लेयर, डिज़ाइन-सिस्टम कॉम्पोनेंट — रजिस्टर कर सकता है ताकि मॉड्यूल उनका उपयोग कर सकें ([Native components](https://nsh.dev/translations/hi/docs/native-components.md))।

यही तंत्र ऐप को **इंटरफ़ेस के रूप में जवाब देने** की सुविधा भी देता है। एक मॉडल छोटा-सा TSX मॉड्यूल लिखता है (फ़ॉर्म, चार्ट, बुकिंग कार्ड), आपका सर्वर उसे जाँचता, बनाता और साइन करता है, और ऐप उसे नेटिव रूप में दिखाता है:

![From a prompt to native UI: a model writes a TSX module; your server builds, checks and signs it; across the trust boundary, the app verifies the package, runs it in a sandbox with the limits and capabilities it set, and shows it with the platform's own UI.](https://nsh.dev/diagrams/ai-flow-light.svg)

iOS पर, होस्ट का हिस्सा बस कुछ पंक्तियों का होता है:

```swift
let app = NshAppView()                         // a UIView: place it anywhere
try app.grantCapabilities(#"{ "network": { "hosts": ["api.example.com"] } }"#)
let info = try await app.loadPackage(at: downloadedFile, trust: trust)   // verified, then run
```

<a id="ai-friendly"></a>

## AI-फ़्रेंडली

NSH को AI के साथ लिखे जाने वाले सॉफ़्टवेयर के लिए डिज़ाइन किया गया है, जनरेट की गई स्क्रीन के लिए भी और पूरे ऐप्स के लिए भी:

- **हर प्लेटफ़ॉर्म के लिए एक ऐप मॉडल।** मॉडल को UI लिखने का केवल एक तरीका सीखना होता है, और नतीजा फ़ोन, डेस्कटॉप और वेब पर चलता है; NSH हर प्लेटफ़ॉर्म के अनुसार इंटरैक्शन को ढाल लेता है, इसलिए कुछ भी छह बार जनरेट नहीं करना पड़ता।
- **काम के अनुसार Rust या TSX।** पूरे ऐप्स और परफ़ॉर्मेंस-क्रिटिकल मॉड्यूल के लिए Rust, स्क्रीन, प्लगइन और हर अनुरोध पर जनरेट होने वाले UI के लिए TSX — दोनों एक ही इंजन पर।
- **एक सटीक, जनरेट किया हुआ कॉन्ट्रैक्ट।** हर एलिमेंट, प्रॉप, स्टाइल की और मॉड्यूल के लिए TypeScript डिक्लेरेशन Rust सोर्स से जनरेट किए जाते हैं (`.nsh/types`), और Rust API टाइप्ड हैं, इसलिए जनरेट किए गए कोड को कंपाइलर जाँचता है। ये डॉक्स मॉडलों के लिए सादे टेक्स्ट के रूप में उपलब्ध कराए जाते हैं ([`llms.txt`](/llms.txt), [`llms-full.txt`](/llms-full.txt))।
- **पूरे चक्र के लिए एक कमांड लाइन।** एक एजेंट ऐप बनाता है, उसे बिल्ड करता है, किसी टार्गेट पर चलाता है, उसके टेस्ट चलाता है, नतीजा पढ़ता है, सुधार करता है और पैकेज करता है, यह सब `nsh` के ज़रिए। `nsh test` बिना डिवाइस के हेडलेस चलता है, और त्रुटियाँ तथा बनाए गए व्यू रिपोर्ट करता है; कंपाइलर इन-प्रोसेस (`nsh_bundler::compile_module`) और ब्राउज़र में ([Playground](/playground)) भी चलता है।
- **अविश्वसनीय होने पर भी चलाना सुरक्षित।** रन टाइम पर डिलीवर किया गया जनरेट कोड अविश्वसनीय कोड है: वह साइन होकर आता है, सीमाओं वाले VM में चलता है और केवल उन्हीं क्षमताओं तक पहुँचता है जो होस्ट देता है।

<a id="where-it-runs"></a>

## यह कहाँ चलता है

| प्लेटफ़ॉर्म | आवश्यकता | बैकएंड | इसके साथ एम्बेड होता है |
|---|---|---|---|
| [iOS](https://nsh.dev/translations/hi/docs/ios.md) | iOS 15.0+ | UIKit | `NativeShell.xcframework` |
| [Android](https://nsh.dev/translations/hi/docs/android.md) | Android 9+ | Android views | `nsh.aar` |
| [macOS](https://nsh.dev/translations/hi/docs/macos.md) | macOS 14+ | AppKit | `AppView` |
| [Windows](https://nsh.dev/translations/hi/docs/windows.md) | Windows 10 1809+ | Win32, Direct2D | `AppView` |
| [Linux](https://nsh.dev/translations/hi/docs/linux.md) | GTK 4.14+ | GTK 4 | `AppView` |
| [Web](https://nsh.dev/translations/hi/docs/web.md) | आधुनिक ब्राउज़र | HTML | `createPlayer`, iframe |
| [GPUI](https://nsh.dev/translations/hi/docs/gpui.md) | डेस्कटॉप | GPUI | `AppView` (GPUI, GPUI Kit ऐप्स) |
| Mac Catalyst | macOS | UIKit | डेवलपमेंट के लिए (`--target catalyst`) |

![One module, many hosts: the same bundle and Rust runtime on iOS, Android, Linux, macOS with AppKit and Windows with Win32 / Direct2D, GPUI on all three desktops, and web pages drawn with HTML.](https://nsh.dev/diagrams/platforms-light.svg)

<a id="native-shell-and-gpui-shell"></a>

## Native Shell और GPUI Shell

[Longbridge](https://longbridge.com) NSH को अपने क्लाइंट्स के लिए बनाता है। पहली ज़रूरत मोबाइल क्लाइंट के लिए एक प्लगइन लेयर की थी, और शुरुआती बिंदु [GPUI Shell](https://gpui-kit.com/shell) था, जो [GPUI](https://gpui-kit.com) डेस्कटॉप ऐप्स को JavaScript में एक्सटेंसिबल बनाता है। फ़ोन पर, GPUI द्वारा खुद ड्रॉ किए गए UI को वह सब दोबारा बनाना पड़ता जो प्लेटफ़ॉर्म पहले से करता है — टेक्स्ट सेलेक्शन और उसका मेन्यू (Copy, Share, Translate, Look Up), इनपुट मेथड, एक्सेसिबिलिटी, हर iOS रिलीज़ के साथ आने वाले विज़ुअल मटीरियल — और हर मोबाइल टीम को एक नया UI स्टैक अपनाना पड़ता। इसलिए NSH हर प्लेटफ़ॉर्म के अपने UI से रेंडर करता है, और यह उस प्लगइन लेयर से बढ़कर हर प्लेटफ़ॉर्म पर पूरे ऐप्स के लिए एक फ़्रेमवर्क बन गया।

दोनों की स्थिति अलग है। GPUI Shell GPUI डेस्कटॉप एप्लिकेशन को एक्सटेंड करता है; Native Shell फ़ोन, डेस्कटॉप और वेब पर नेटिव ऐप्स के लिए एक फ़्रेमवर्क है, और इसका GPUI बैकएंड NSH ऐप्स को GPUI और GPUI Kit ऐप्स में एम्बेड करता है ([GPUI](https://nsh.dev/translations/hi/docs/gpui.md))।

<a id="how-it-compares"></a>

## तुलना

पूरे ऐप्स के लिए, NSH क्रॉस-प्लेटफ़ॉर्म फ़्रेमवर्क जैसे React Native, Flutter, Qt, GPUI, Slint, Electron और Tauri के बीच आता है; रिलीज़ के बाद डिलीवर होने वाले UI के लिए, वेब व्यू, सर्वर-ड्रिवन UI और मिनी-प्रोग्राम कंटेनरों के बीच। इसका चुनाव है: एक ऐप मॉडल के तहत हर प्लेटफ़ॉर्म का अपना UI और इंटरैक्शन, ऐप की भाषा के रूप में Rust और उसके साथ TSX। [Comparing approaches](https://nsh.dev/translations/hi/docs/comparison.md) में हर एक पर विस्तार से चर्चा है।

<a id="next-steps"></a>

## अगले कदम

- [Installation](https://nsh.dev/translations/hi/docs/installation.md) और [Getting started](https://nsh.dev/translations/hi/docs/getting-started.md): `nsh` प्राप्त करें, Rust या TSX में पहला ऐप लिखें और उसे हर प्लेटफ़ॉर्म पर चलाएँ।
- [Building with Rust](https://nsh.dev/translations/hi/docs/rust.md): Rust में लिखे ऐप्स, और उनके ऊपर TSX।
- [Platforms](https://nsh.dev/translations/hi/docs/platforms.md): क्या कहाँ चलता है, और हर प्लेटफ़ॉर्म पर कैसे चलाएँ, पैकेज करें और एम्बेड करें।
- [JSX and components](https://nsh.dev/translations/hi/docs/jsx-and-components.md) और [Reactivity](https://nsh.dev/translations/hi/docs/reactivity.md): वे दो विचार जिन पर बाकी सब कुछ टिका है, Rust और TSX दोनों में।
- [Signed packages](https://nsh.dev/translations/hi/docs/signed-packages.md) और [Sandbox and capabilities](https://nsh.dev/translations/hi/docs/sandbox-and-capabilities.md): मॉड्यूल डिलीवर करें और तय करें कि वे क्या कर सकते हैं।