A Salesforce native app is a managed package that installs into each customer's Salesforce org, so its objects, pages, automation and Apex code run on the customer's own platform instead of on your servers. For a SaaS company, the real choice is not native or not native. It is which parts of your product should live inside the customer's org, and which should stay on your backend and connect over the API. Most products that sell to Salesforce customers end up with both, a package for the screens and logic users touch every day and your service for the heavy processing.
That choice shows up in enterprise deals, because a buyer who runs on Salesforce wants to install, test and approve something in their own system. Appnigma's marketplace apps work covers exactly that. It is built by ex-Salesforce engineers and promises "a native app, marketplace listing preparation, and review support." If you are an admin building an app for your own org, Salesforce's Lightning App Builder guide is the better place to start. If you meant the Salesforce mobile app, see Salesforce Help.
Updated October 2026. Checked against the Salesforce Developer Limits guide, the Apex Developer Guide, the 2GP Developer Guide and the ISVforce Guide. The earlier version listed build tools aimed at admins, said native apps use zero API calls in every case, said customers skip vendor security review, quoted a shorter review time than Salesforce's own estimate and recommended WITH SECURITY_ENFORCED. This update corrects those and adds API arithmetic for one customer org, the parts of a product that belong in the package and the install details your sales team will be asked about.
Native app or off-platform app with a connector
The difference is where your code runs and what the customer's org pays for each action. A native app runs inside the org as packaged metadata. An off-platform app runs on your infrastructure and reaches into the org through Salesforce APIs, usually with an OAuth connection the customer approves.
| Question a buyer asks | Native app (managed package) | Off-platform app with a connector | Source |
|---|---|---|---|
| Where does the logic run? | In the customer's org, as Apex, flows and Lightning pages | On your servers | Components Available in 2GP |
| Does it use the org's daily API requests? | Not for work done inside the org | Yes, every REST, SOAP or Bulk call counts | API Request Limits and Allocations |
| How is it installed? | From the listing or an install link, by an admin | The customer connects an account from your product | Installing Packages |
| How does it get updates? | New package versions, which you can push to customer orgs | You deploy your own service | Push Upgrade for 2GP |
| Is the code visible to the customer? | Apex in a managed package is hidden in the installed org | Not applicable, it never enters the org | Components in 1GP |
| Does it need security review to list? | Yes | Yes, as a Salesforce Platform API solution | How the Security Review Works |
The last row surprises many SaaS teams. Salesforce reviews managed packages and also "Salesforce Platform API solutions" before they can be listed, per How the Security Review Works. Staying off-platform does not skip the review if you want a listing. It changes what gets tested. If you are weighing middleware for the connector side instead, our comparison of Salesforce integration tools covers that decision.
What a native app saves on the customer's API limits
Work done inside the org does not touch the org's daily API allocation, because that allocation only counts calls from outside. Salesforce's list of APIs that count starts with "the Lightning Platform REST API" and also names the SOAP API and both Bulk APIs, per API Request Limits and Allocations. A trigger in your package that updates a related record when an opportunity closes uses none of them.
The allocation is shared by the whole org, not handed out per app. "Limits and allocations are not on a per-user basis," per the same page. An Enterprise Edition org gets 100,000 requests per 24 hours plus 1,000 per Salesforce license. Salesforce's own example is "an Enterprise Edition org with 15 Salesforce licenses" at 115,000. Your connector competes with every other integration the customer runs for that budget.
Here is what that means for one customer, as arithmetic from the documented limits. Take an Enterprise org with 200 Salesforce licenses. Its daily allocation is 100,000 plus 200 times 1,000 requests. That comes to 300,000. Say your off-platform app writes back 20,000 changed records a day one call at a time. That uses 20,000 requests, about 7% of the org's budget. Batching the same writes with sObject Collections, which can "update up to 200 records" per request according to the REST API guide, brings it to 100 requests. A native package doing the same writes inside the org uses zero, though it still has to fit Apex governor limits per transaction.
Native does not mean zero API traffic in every design. Three cases still cost something.
- Your package calls your backend. Apex callouts don't use API requests, but they have their own limits, 100 callouts per transaction and 120 seconds of total callout time, per the Apex Developer Guide.
- Your backend writes back into the org. Those writes are REST or Bulk calls and count like any connector's.
- Your service listens to events from outside. Events delivered to Apex triggers and flows "don't count against the delivery allocation," but external subscribers do, per Default Platform Event Allocations.
So the honest pitch to a buyer's admin is specific. Say which actions run inside their org at no API cost and which ones still call in, and roughly how many per day.
Which parts of your product belong in the package
The parts that should live in the package are the ones users touch inside Salesforce or that must react the moment a record changes. That usually means custom objects for your data, Lightning pages or components on the record page, permission sets and the triggers or flows that respond to record changes. Flows, permission sets and Lightning pages are all packageable in second-generation managed packages, per the 2GP component list. Platform events let both sides react "in near real time when the event occurs," per Salesforce's event-driven architecture page.
Work that is heavy, long running or shared across customers usually stays on your backend. Model inference, large data processing and anything that needs your own database or third-party systems fit there, with the package calling out through a named credential. The split also follows governor limits. Packages that passed security review "get their own set of limits for most per-transaction limits," but "the limit on maximum CPU time" is shared with everything else in the transaction, per Execution Governors and Limits. A package that does CPU-heavy work inside a customer's busy trigger chain is the one that causes errors after install.
Two decisions are hard to undo, so make them first. A namespace "is assigned to a second-generation managed package (managed 2GP) at the time that it's created, and can't be changed," per Namespaces for 2GP. The data model you package also becomes the customer's data model, because their reports, automations and integrations start depending on your fields the week they install. Our managed package guide covers the 2GP build workflow, and the explainer on what a managed package is covers the basics behind it.
Does a native app skip the customer's vendor review?
No. Passing Salesforce's security review gets you a listing, not a pass through the buyer's own procurement. Salesforce states that "Salesforce makes no guarantees regarding the quality or security of any Partner Application," and treats managed packages as "Non-SFDC Applications as defined in Salesforce's Main Services Agreement," per Security Requirements for ISV Partners. The review itself is "a black-box, time-limited process," per How the Security Review Works. Expect the same vendor questionnaire, SOC 2 request and contract review you would face without a package.
What the native app and listing do change is what the buyer can inspect. Our marketplace apps page puts it this way. "A marketplace listing gives buyers a place to review the app, its permissions, and installation details." An admin can install it in a sandbox and test it against their own data. AppExchange use is also widespread on the buyer side. Salesforce reports that 91% of Salesforce customers and 90% of the Fortune 500 use AppExchange apps, on its What is AppExchange page.
Plan the review time into the launch, not into the build. Salesforce says "Approximately 4 to 6 weeks after you submit a solution for an initial review, your security review is complete," per Act on Security Review Results, and it labels those time frames as estimates. Your backend is in scope too, since scans must "include all external endpoints that run independently of the Salesforce platform," per Test Your Entire Solution. Our post on how long the security review takes breaks down each stage.
How a SaaS company gets a native app built
Whoever builds it, the path has the same steps. You join the Salesforce Partner Community, which Salesforce names as the start of "your partnership journey" on Join the Partner Community. Then you register a namespace, build the package in source control, write Apex tests, pass security review and set up licensing. With 2GP, "your source of truth with managed 2GP is the package metadata in your version control system," per Why Switch to 2GP. A version needs "a minimum 75% code coverage requirement" before release, per Code Coverage for 2GP. The License Management App "is installed in all partner business orgs" so you can track who has a license, per Install the LMA.
The real decision is who does that work and who maintains it afterward. Three options are common.
| Option | Fits when | What to plan for |
|---|---|---|
| Your own engineers | Salesforce is a core, long-term channel and you can staff Apex and packaging skills | Hiring or training, plus ongoing upgrades with each Salesforce release |
| A Salesforce development partner | You want a team that builds on contract, see our guide to AppExchange development company services | Scope, handover and who owns fixes after launch |
| Appnigma marketplace apps | You want the app, listing and review handled as one scoped project while your engineers stay on the product | A separate maintenance retainer for fixes and upgrades after launch |
Appnigma scopes marketplace apps as "development, marketplace preparation, and install documentation in one scoped project." Review support covers "Salesforce security review preparation and responses," and the page is clear that platform approval and queue timing stay with Salesforce. One example from that page is Warmly, whose native Salesforce app took two weeks to build and eight weeks from kickoff to AppExchange launch, "including six weeks of Salesforce security review." The page calls that a project example, not a guaranteed schedule. Warmly's team spent about 40 engineering hours on the project, mostly in requirements calls, and Salesbricks reported "no engineering sprints diverted to the Salesforce package." If the native app is one piece of a larger integration roadmap, Appnigma's done for you delivery adds a named integration engineer who builds and maintains the integrations your customers need.
Mistakes that slow down a first native app
- Writing queries with WITH SECURITY_ENFORCED. "With API version 67.0 and later, you cannot use the WITH SECURITY_ENFORCED clause," per Apex Versioned Behavior Changes. Salesforce recommends WITH USER_MODE in the SOQL reference.
- Sending prospects to Get It Now for a sandbox trial. "Get It Now supports package installation in production environments only," and sandbox installs use Try It, per Installing Packages.
- Counting on separate governor limits before review. "Namespaces in non-certified packages don't have their own separate governor limits," per Execution Governors and Limits. Test a beta in an org that already runs other packages.
- Leaving your API or webhook endpoints out of the scan. The review covers external endpoints, so scan them before you submit.
- Treating the listing as a lead source. A listing helps buyers find and evaluate the app. Our marketplace apps page says plainly that it "is not a promise of inbound leads."
Frequently Asked Questions
What is a Salesforce native app?
It is an app delivered as a managed package that installs into a customer's Salesforce org, so its objects, pages and Apex code run on the Salesforce platform. Apps that run on outside servers and call Salesforce APIs are off-platform apps, even if they connect well.
Does a native Salesforce app use API calls?
Not for work it does inside the org, since the daily allocation only counts outside calls such as REST, SOAP and Bulk API. Calls from your backend into the org still count, and Apex callouts out of the org have their own limit of 100 per transaction.
Do I still need security review for an off-platform app?
Yes, if you want an AppExchange listing. Salesforce reviews Salesforce Platform API solutions as well as managed packages, and the scans include your external endpoints.
How long does it take to launch a native Salesforce app?
Build time depends on scope. Salesforce estimates about 4 to 6 weeks for an initial security review after you submit, so plan the launch date around both.
Can Appnigma build our native Salesforce app?
Yes. Appnigma's marketplace apps project covers the managed package, listing preparation, security review support and install docs, with maintenance available on a separate retainer.
About the author
Sunny Chauhan is the co-founder and CEO of Appnigma AI, which builds and maintains customer integrations and native Salesforce and HubSpot apps for B2B SaaS teams. Before Appnigma, he was on Salesforce's AppExchange team, where he worked with more than 300 SaaS partners. He has spent close to a decade on the Salesforce platform, including work at Zennify, and holds Salesforce certifications including Platform Developer II, Platform App Builder, Administrator, Data Cloud Consultant, and AI Associate.
Related Articles
- What Is a Managed Package in Salesforce
- Salesforce Managed Package Guide
- How Long the Salesforce Security Review Takes
- Salesforce Integration Tools Compared
Sources
- Salesforce Developers, Salesforce Developer Limits and Allocations, API Request Limits and Allocations
- Salesforce Developers, REST API Developer Guide, Update Records Using sObject Collections
- Salesforce Developers, Apex Developer Guide, Callout Limits and Limitations
- Salesforce Developers, Apex Developer Guide, Execution Governors and Limits
- Salesforce Developers, Apex Developer Guide, Versioned Behavior Changes
- Salesforce Developers, SOQL and SOSL Reference, WITH
- Salesforce Developers, Platform Events Developer Guide, Default Platform Event Allocations
- Salesforce Developers, Platform Events Developer Guide, Event-Driven Software Architecture
- Salesforce Developers, 2GP Developer Guide, Components Available in Second-Generation Managed Packages
- Salesforce Developers, 2GP Developer Guide, Namespaces
- Salesforce Developers, 2GP Developer Guide, Push Upgrade
- Salesforce Developers, 2GP Developer Guide, Code Coverage
- Salesforce Developers, 2GP Developer Guide, Why Switch to Second-Generation Managed Packages
- Salesforce Developers, 1GP Developer Guide, Components in First-Generation Managed Packages
- Salesforce Developers, 1GP Developer Guide, Install the License Management App
- Salesforce Developers, AppExchange Install Guide, Installing Packages
- Salesforce Developers, ISVforce Guide, How the Security Review Works
- Salesforce Developers, ISVforce Guide, Act on Security Review Results
- Salesforce Developers, ISVforce Guide, Test Your Entire Solution
- Salesforce Developers, ISVforce Guide, Security Requirements for ISV Partners
- Salesforce Developers, ISVforce Guide, Join the Partner Community
- Salesforce AppExchange, What is AppExchange
