18

Security Review Fees (aka Listing Fees): As of September 1 2013, the security review for new paid apps is $2,700 USD per app, up from the previous cost of $300 USD. The annual review fee (aka "AppExchange listing fee") for paid apps remains $150 USD per app. This change will not impact partners with free AppExchange apps (which I believe currently get ...


17

Packaging the connected app allows administrators who install the app to control which of their users can use the application. Rather than the coarse ability to block or not block an app (seen in Setup -> Manage Apps -> Connected Apps Oauth Usage), you get the ability to control the security settings for the app in a more finely grained manner (seen in ...


14

I don't think you will need to worry about Canvas App being embedded in your visualforce for passing through lightning ready certification for your application .Since canvas app is essentially a mashup with external system,you don't have to match CSS with lightning design system . For lightning Ready Certification, here are key things SFDC looks in your ...


13

Having been involved in one of those applications, i can say that there was no official list of things they provided, maybe their will be in due course, though the documentation does a pretty good job of describing the features to use. As such having your package make use of one or more of the following Salesforce1 features is going to allow you to be ...


11

I believe the terminology has changed from aloha apps to ISV apps. Previously the main advantage was that installed ahola apps didn't count towards various org limits and could work with Group and Professional editions of Salesforce. In a previous Salesforce release at least some of the advantages were passed on to all managed packages. Not much ...


11

The proper design would be to have the two packages be "extensions" of the core library. This would require all clients to install two packages to use either app, and three packages to use both apps. While slightly more complicated for installs (and possibly undesirable), it would allow you to maintain less code and configuration. Here's how it works: you ...


11

You cannot create two managed packages in one dev org, you can only have one namespace created per DE org. Your options are to create another DE org and install the first managed package in there. Then, once you start to reference the first managed package in the new DE org, then that package becomes an extension of the first. Once you release your second ...


10

If you're using Salesforce to Salesforce to bring data from your customers org into Salesforce you're going to run into two scalability issues. First, Salesforce to Salesforce transactions count against your daily API limit. If you have a lot of orgs connecting to yours there is a very good chance you could start exceeding your daily limit. Second, ...


10

My understanding is that ISVForce is for apps installed into existing Salesforce customer's systems. The Embedded license allows you to sell your app standalone and resell Force.com licenses along with it. To my knowledge, an embedded license takes care of your customer needing to talk to Salesforce at all. You are effectively reselling a license and paying ...


10

There is no necessity that if we are making a managed package then it should be on Appexhange. Appexchange is basically a marketplace for salesforce as Itunes is for Apple. To install a package: When create a package and upload it, after successful upload it provide installation link. It can be gone through Build | create | package and select your ...


10

With Enterprise Distribution: You don't need to include UDIDs in your provisioning profile; any device can install the app You must host the IPA somewhere and provide an installation page (could be just a simple link) Apple can and will lay the smack down on you if they suspect you are circumventing the app store If you're not using an Enterprise profile, ...


10

As of now, Salesforce does not do any anti-virus scanning. However, there is an idea here which is under point threshold. Until this is implemented you can use 3rd party apps from AppExchange such as this one.


10

Yes, its possible to install a custom application from an alternate source than app exchange. Following are different options: Packages: Developers can distribute links of their managed or unmanaged packages (custom apps), without publishing them to appexchange. Using this links admins can install the application in any Developer/Sandbox/Production orgs. ...


9

Assuming your application uses at least one custom tab, I would leverage the 'splash page' functionality of custom tabs to display a landing page on your website, with appropriate links off to docmentation, FAQs and the like. A bonus with having documentation elsewhere means you do not need to roll out a new version of your package just to update the ...


9

I think your best bet is to stay with the current location and link the existing org. As you point out you will loose upgradability for your existing customers. And migrating them will involve (depending on the number of custom objects and dependencies they have elsewhere in their orgs) quite complex and not great from a customer perspective. In reality ...


9

Absolutely do NOT include your documentation in the package itself. Here's why: Chances are your documentation team is not (or will not) be the same people as your developers. Your need to update the documentation will not be on the same schedule as your software release schedule. Including documentation in the package ties the two together. I mean, do you ...


9

Connected Apps require your subscriber (your customer) to go through a oAuth authentication flow (with a user of their choice) to allow your application to connect to their org. You cannot and should not attempt to cicrumvent this process for a variety of reasons, most of which security based as you hint at in your question. This however does not mean you ...


9

FLS You must make sure that you honor FLS. That does not mean that every trigger, every utility function, etc must check every single field before attempting to access or update the value. It simply means that the front-end UI (any Visualforce) must use apex:inputText or apex:outputText to honor visual field level security, or that any other types of input, ...


9

A really good breakdown of the difference between OEM and ISV has been posted on Linkedin here and copied below Key differences: (1) the app creator's contracts with Salesforce and end users (2) what end users receive. When you sell an app under an OEM agreement, you are selling the end user BOTH Salesforce Platform user licenses AND package ...


9

Although this post is from last year, I would like to address it since it's apparently coming up in search results for those looking to post unmanaged packages to the AppExchange, and the main answer currently features out-of-date info. To confirm, unmanaged packages are not accepted for security review or posting on the AppExchange. I've put together some ...


9

A free app is one in which salesforce security review won't cost you any money and your app can be installed by consumer free of cost. In a paid app you can control the license and the consumer will have to go through a payment portal to make payment and purchase license. Salesforce provides you with a LMA application to manage licenses. LMA is a Salesforce ...


9

To list on the app exchange you need to be a partner. If the app is a paid managed app you will have to pay the security review fee. Unmanaged apps cannot be listed IIRC Additionally you will have a Revenue share (something like 25% now I think) with SF. The cost would be the $2,700. The impact on revenue would be 25% of collected revenue from the app. So ...


8

You can't actually create a user and specify a password for it so you're going to run into a dead end right there. It sounds like the real time API will be running on the clients' orgs and you'll be connecting to those to consume data. If that's the case then things are definitely going to get complicated. You can not create a new user in the client org, ...


8

I have some notes on using the BURP scanner to test a web service for submission to the security review - Using the Burp Suite to test a Web Service that is consumed in a Salesforce app. The basic idea is: Have BURP intercept typical requests by acting as a proxy as you browse around the site. If it is Salesforce calling a web service you will need to ...


8

Great question. First, watch this video: Ready to Partner with Salesforce.com (ISVforce or OEM)? (http://www.youtube.com/watch?v=_oV9LthQ5O0) ISV companies can sell licenses to their own apps (which I would say is the most common - this would be using the AppExchange to sell, say, 5 licenses of a managed package app. With new AppExchange checkout features ...


8

A custom app in Salesforce is not the same thing as an AppExchange app. A custom app is: An “app” is a group of tabs that works as a unit to provide application functionality. Salesforce provides standard apps such as Sales and Call Center. You can customize the standard apps to match the way you work. So, essentially, a custom app is just a ...


8

If the primary pain point is the duplication of code (not the duplication of objects or fields) then an approach is to create a separate project in your version control system for the common code. You can then add that code to both packages using mechanisms such as svn:externals via your IDE. So each managed package gets an identical copy of the code. This ...


8

Update Salesforce does not allow unmanaged packages to be part of appexchange .You will have to convert them to managed packages . You can publish your apps as managed package to the appexchange provided you sign up as partner.Do not confuse that partner has to be some consulting firm .Anyone can be a partner Even as a solo developer you can be a part of ...


8

You can join the partner program as an individual ISV partner and list free apps on the app exchange (managed or unmanaged) at no cost (I've done so!). However, you'll need to be fairly persistent with folks at SFDC to keep your stuff moving, they seem to forget about the small players sometimes.


8

To create a managed package,first you will need to create a namespace for your org . Note that once you choose a namespace you cannot change it . Once you have namespaced an org you can create a managed package application from the package manager .Note that if you do not namespace an org ,you will never get an option to make a package managed .


Only top voted, non community-wiki answers of a minimum length are eligible