Can I upload package to appexchange if none of the class is marked by 'with sharing' keyword?

Question

I had created a managed package which performs the following:

1. Update the custom fields(part of package) on account object.
2. TO Update these fields, I had a scheduler class(say A) which calls a batch class(say B) which inturn calls apex class(say C) that updates the fields on an hourly basis.
3. I also have a inline vf page on account object which takes some input and makes a webservice callouts and updates the same custom fields mentioned in point 1 and reloads the account detail page. The controller for this page is same class(class C) which is being called from batch class(class B) mentioned in pt. 2
4. I have a post install script which I created tho schedule the apex mentioned in pt. 2(class A)

ALSO see my previous question: Sobject type not supported in Managed Package

SO the flow is:

POST INSTALL script calls class A; Class A calls Class B; Class B calls Class C.

Vf Page also invokes class C.

When I install the package, it was successful. But when the scheduler class runs, I get error saying "sobject type account is not supported".

After some research I found out that, in order for this to work, I need to remove the "'with sharing" keyword from all the classes directly/indirectly referred from the post install classes. This essentially means that all the classes in my package will have to be marked either as "without sharing" or simply none of them needs to have "with sharing" keyword.

Below is a link for reference: Install Script Batch Job failing (sObject type 'Contact' is not supported)

So my question is that is it possible to have my application uploaded on appexchange if all the classes in my package are not marked by "with sharing" keyword?

Answer 1

There is no restriction on uploading a package related to with/without sharing. So yes, you can upload it, you can install it, you can link it to your AppExchange listing.

The area you may get into difficulty is if your lack of using "with sharing" causes issues in security review. Visualforce controllers and code called from Triggers generally is encouraged or required to have "with sharing" enabled, depending on what objects you are accessing. The requirement is not highly transparent from the security team, but my advice several months ago was that actions on custom objects that are part of the package are not required to check sharing and CRUD/FLS, but actions on standard CRM objects (Account etc) are required to check sharing and CRUD/FLS.

In your case, you may be able to satisfy both that requirement, and your installer requirement, by having a thin API layer on top of your existing classes that is marked "with sharing" which simply delegate through to the implementations in your lower-level classes, where you do not specify a sharing mode. Your installer accesses the lower-level API (without sharing), and your controller/trigger code accesses the "with sharing" API, thereby inheriting the "with sharing" mode when it calls through to your core implementation code.

If you have concerns about security review, your best bet is to schedule office hours with the security team.