Do you have a great idea for a new mobile app? One that extends the capabilities of Salesforce’s core products, or brings your own product to more customers? Do you want to offer your customers the unrivaled user experience of a native mobile app, with full access to device hardware, or extensive offline capability?

Whether you’re a fast-growing start-up, well-established software vendor, or independent developer, I want to show you how easy – and potentially rewarding – it is to develop, distribute and sell native mobile apps that integrate with the Salesforce App Cloud. It’s a powerful, hugely-scalable, and very developer-friendly platform.

(This post covers native iOS apps, but much of the information is equally applicable to native Android apps, too.)

A Real-World Example

I’ll explain the entire process by means of a real, but relatively simple example: a native iOS app that I built recently. Then I’ll discuss some variations in the process that might apply to your app.

My app is called “Limits for Salesforce.” I wrote it a few months ago in Swift 2, for iPhones running iOS 9+. The source code is here, the AppStore listing is here, and the AppExchange listing is here.

The Limits app is intended for Salesforce administrators, IT support reps and developers. Salesforce is a multi-tenant platform, and its computing resources are shared by all users. In order to ensure that no app unduly affects the performance of other apps, the platform’s resources are rationed and subject to limits. For example, your Salesforce environment (“org”) may be allotted 1 million API calls per day, or a certain number of outbound emails, or a maximum amount of file storage. The Limits app provides a dashboard-like, real-time monitor of about 30 resource limits, as you can see in this screenshot.

Six Steps to Success

At a high level, these are the steps I followed to develop and publish the Limits app:

  1. Get a free Salesforce Developer Edition
  2. Create a Salesforce Connected App
  3. Develop the iOS code
  4. List the mobile app on the Apple AppStore
  5. Package the Connected App
  6. List the app on the Salesforce AppExchange

Let’s dive into each step:

1. Get a free Salesforce Developer Edition

You can sign up for a free, full-featured Salesforce Developer Edition. If you’re new to developing on the Salesforce platform, check out the Salesforce Developers website for a wealth of information and tools. You can blaze your trail with Trailhead: the fun way to learn Salesforce, and you can ask questions and get answers on the Salesforce Developer forums and the Salesforce Stack Exchange.

2. Create a Salesforce Connected App

Log in to your new Developer Edition and follow these directions to the “New Connected App” page. Complete only the required fields for now. You may not be able to fill all the fields yet; for example, you’ll come back later to add the value for ‘App Binary URL’ once you have a link to your AppStore listing.

I also created images for the ‘Logo Image URL’ and ‘Icon URL’ – it’s a nice way to brand your app, and the images appear in various places, such as on the Salesforce-hosted app authorization page where your users will be asked to allow your app to access their data.

Check the ‘Enable OAuth Settings’ box and you’ll see the ‘Callback URL’ and ‘Selected OAuth Scopes’ fields. The ‘Callback URL’ can be any URL that you choose – it doesn’t matter, as long as the URL is properly formatted. This is the URL to which Salesforce will redirect users after they authorize your application. Since we’re dealing with a native mobile app, iOS will use the redirect URL to launch your app. You’ll see shortly where this redirect URL fits in your code.

For ‘Selected OAuth Scopes’ choose at least the following three scopes:

  • Access and manage your data (api)
  • Access your basic information (id, profile, email, address, phone)
  • Perform requests on your behalf at any time (refresh_token, offline_access)

Save your changes and note the value for your new Connected App’s ‘Consumer Key.’

3. Develop the iOS code

For the Limits app, I used Swiftly Salesforce, an open-source, all-Swift framework that I published earlier this year. You could instead use the Salesforce Mobile SDK for iOS, written in Objective-C, with versions for Android and Windows.

Swiftly Salesforce is very easy to use, and enables elegant, painless coding of complex, asynchronous Salesforce API calls. You can find the complete source code for the Limits iOS app here. In the code for my app delegate,  you can see how the consumer key and callback URL from the Connected App definition are included.

(Swiftly Salesforce has since been upgraded for Swift 3, and there’s a slightly different, even easier way to configure your iOS app with the Connected App settings, as you can see in this updated app delegate.)

4. List the app on the Apple AppStore

Create an AppStore listing and submit your app for review by Apple. At this point, you could go back to the Connected App definition and add the link to the AppStore listing in the ‘App Binary URL’ field.

5. Package the Connected App

A managed package is the standard way to distribute Salesforce apps, and it can contain lots of different components. You must use a Developer Edition org to create the package. For the Limits app, the only component I needed to include was the Connected App definition – the app doesn’t require any custom objects or fields (i.e. database tables or columns) or other back-end features. See the ISVForce Guide for lots more information on packaging apps.

6. List the app on the Salesforce AppExchange

Prepare the AppExchange listing, and submit the managed package for security review. Salesforce goes to extraordinary lengths to protect its customers from potentially-rogue third-party apps, and the security review process can be quite rigorous. For much more detailed information on the security review process and fees, check out the “Security Review” section of the Salesforce Partner Community.

For the Limits app, the security review was pretty straightforward since my managed package contains only the Connected App definition. The app doesn’t access any other endpoints beside Salesforce – and I followed best practices for secure coding, including the requirement to store the refresh token securely. Swiftly Salesforce automatically handles that for me, and stores the refresh token in the iOS keychain. My app passed the Salesforce security review on the first try – but don’t be discouraged if yours doesn’t, it typically requires additional attempts. You can find the AppExchange listing here.

Variations Applicable to Your App

By now you may have some questions specific to your app:

“You’re giving away your ‘Limits’ app for free. How can I sell my app?”

Check out the Salesforce Partner Community for lots of resources to help you build, sell and distribute your app.

“The Salesforce security review fee is $2,700 for paid apps. I’m launching a new business from my local coffee shop and that’s a lot of money for me. Is Salesforce the right platform for a mobile app startup?”

Yes! The Salesforce Platform is ideal for a mobile app startup. It’s reliable, fast, and scalable-on-demand, so you can focus entirely on your app and growing your business. The platform has great APIs, lots of free resources for developers, and a vibrant developer and partner community – and you get access to a huge ecosystem of paying customers.

The security review is a worthwhile investment in earning the trust and confidence of potential customers, and should be a key part of your go-to-market strategy. That said, you are not technically required to undergo the review. You could still complete the first four of the six steps I listed above: get a free developer edition, define a Connected App, develop the iOS code, and list your mobile app on Apple’s AppStore – but you wouldn’t be able to sell your app on the Salesforce AppExchange until it has passed the security review.

“My app requires custom, back-end components that are not available out-of-the-box in Salesforce, like custom objects (i.e. database tables), fields (database columns), back-end business logic, or custom REST API endpoints. How would my native mobile app work with those components?”

You can easily include all those custom components in your app’s package for one-click installation in your customers’ orgs. While my app required only the Connected App definition, your package would include any custom components required by your mobile app. See the ISVForce guide for more information on packaging back-end components. On the iOS client side, Swiftly Salesforce makes it easy to refer to your custom objects, fields and REST endpoints. (By the way: the standard Salesforce APIs are so comprehensive, that you very likely don’t need to create your own custom REST endpoints.)

“Do my customers have to install anything besides the iOS app?”

If your Salesforce package contains only the Connected App definition, then customers don’t have to install the package in their org in order to use your app. However, if your package contains any custom objects, fields, code, or other back-end customizations, then an administrator of your customer’s org would have to install the managed package in order for your mobile app to work. In any case, it’s useful to offer the package even if it’s not required. By installing the Connected App in their org, administrators can configure fine-grained access control for your mobile app.

Resources to Help You Get Started

About the Author

Michael Epstein is a senior technical evangelist at Salesforce, and works with ISV partners who are building applications on the Salesforce Platform.

LinkedIn: in/mike4aday | twitter: @mike4aday

Get the latest Salesforce Developer blog posts and podcast episodes via Slack or RSS.

Add to Slack Subscribe to RSS