Native App
A native app on Salesforce is a packaged application built entirely on the Lightning Platform using only platform-native building blocks.
Definition
A native app on Salesforce is a packaged application built entirely on the Lightning Platform using only platform-native building blocks. That means Apex classes and triggers, Lightning Web Components or Aura, Visualforce pages, custom and standard objects, flows, validation rules, and platform events. All data, business logic, and user interface live inside the customer's Salesforce org rather than calling external systems for core functionality.
The distinction is sharpest in the AppExchange listing flow, where Salesforce labels every offering as native, composite, or external based on where the work happens. Native apps inherit the platform's security model, sharing rules, field-level security, audit trail, encryption at rest, and disaster recovery automatically. They install through managed packages, share the org's governor limits with everything else running there, and never require a separate login or hosting bill.
Why the native vs non-native choice shapes every install
What 100 percent native actually requires
The AppExchange security review checks whether every functional piece runs on Salesforce. A package qualifies as native when its data lives in custom objects or Big Objects inside the subscriber org, its logic runs as Apex or declarative automation, and its UI renders through Lightning Components, Visualforce, or Lightning App Builder. The moment a feature calls an external API for required functionality (not just an optional integration), the listing drops to composite. A storage layer in S3 or a logic step in AWS Lambda disqualifies the native label even if everything else stays on platform.
Security and sharing come included
Because data sits in standard or custom objects, the partner does not rebuild profiles, permission sets, role hierarchy, sharing rules, or field-level security. Whatever the customer configures for their own objects applies to the package's objects too. Shield Platform Encryption, Field Audit Trail, and Event Monitoring all extend without special integration work. This is the single biggest reason regulated industries (finance, healthcare, government) prefer native packages over composite ones with external data stores.
Composite and connected apps for context
Composite apps split logic between Salesforce and an external service, usually called via callouts and surfaced through a Canvas frame or external services. Connected apps are pure integration shells that authenticate an outside system into Salesforce via OAuth, with no UI of their own. Native is the heaviest investment for the partner but the lightest install for the customer. Composite scales better for compute-heavy workloads. Connected suits headless integrations like ETL pipelines and analytics tools.
Managed packages and namespace prefixes
Native apps ship as first-generation or second-generation managed packages. Every component carries a namespace prefix like acme__Loan__c so it never clashes with the customer's own objects or another vendor's package. Upgrades push through new package versions; the partner can deprecate components but not delete data customers have created. This is why native packages have such long support tails. The partner cannot rip out an object once it ships.
Governor limits are shared, not separate
Because the package runs inside the subscriber's org, it draws from the same SOQL query limit, CPU time, heap size, and DML statement count as the customer's own code. A native app that does heavy batch processing will eat into the customer's daily limits. Partners design around this by using batch Apex with sensible scope sizes, Platform Events for asynchronous handoffs, and avoiding tight loops with SOQL inside them. Composite apps escape these limits by offloading the heavy work elsewhere.
When to deliberately go non-native
Real-time machine learning inference, video processing, OCR on millions of documents, and anything that needs sub-100ms response from a specialized engine usually belongs outside Salesforce. The pattern is: store the system of record natively, push compute-heavy steps to an external service via Salesforce Functions, Heroku, or a customer-managed cloud. Document the architecture as composite on the AppExchange listing so buyers understand the operational footprint before they install.
How to decide if your feature should be native
Before writing the first line of code, run through the native versus composite decision so you know what you are committing to support for the next five years.
- List every data store the feature needs
Write down every entity the app will persist. If all of them can live in custom objects, Big Objects, or files attached to records, you are still in native territory. Any requirement for a relational schema with joins Salesforce cannot express, or for storage beyond the Files cap, pushes you to composite.
- Map each logic step to a platform primitive
Walk the user story step by step and label each step Apex, Flow, validation rule, formula field, or external call. If more than one step needs an external call to function (not just enrich), you are composite. One outbound webhook on success is still native.
- Estimate the governor-limit cost
Add up SOQL queries, DML statements, CPU milliseconds, and heap usage per user transaction. If a single user action could consume more than 20 percent of an org's per-transaction limits, redesign with async patterns or move to composite.
- Confirm the AppExchange security review path
Native packages run through a standard security review that takes 4 to 8 weeks. Composite packages need additional review of the external service's security posture. Plan timeline accordingly and budget for a Checkmarx scan, a Burp Suite penetration test, and a remediation cycle.
All data in subscriber org, all logic in Apex or Flow. Lowest install friction, highest partner support burden, qualifies for AppExchange "native" badge.
Salesforce holds the system of record, external service handles compute-heavy steps or specialized UI. Iframe-style canvas brings the external UI into Lightning.
External system calls Salesforce via OAuth for read/write. No UI in Salesforce. Suits ETL, BI tools, and middleware.
Modern composite pattern. Salesforce invokes a serverless function or Heroku service for heavy compute, gets results back, persists natively.
- Native does not mean "uses no internet". You can still make outbound callouts for optional integrations and stay native, as long as the core flow works without them.
- A managed package cannot be uninstalled if customer data references its custom objects. Customers must delete the data first. Document this in your install guide.
- Namespaces are permanent. Choose a short, distinctive namespace prefix; you cannot change it after the first package version is uploaded.
- Second-generation packaging (2GP) gives you more flexibility than 1GP for component deletion and namespace handling. Default to 2GP for any new native app.
Trust & references
Cross-checked against the following references.
- Packaging Developer Guide: IntroductionSalesforce Developers
- Second-Generation Managed PackagingSalesforce Developers
Straight from the source - Salesforce's reference material on Native App.
- AppExchange OverviewSalesforce Help
- Packaging Developer GuideSalesforce Developers
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Native App in Salesforce?
Q2. What are benefits of native apps?
Q3. What's the trade-off?
Discussion
Loading discussion…