[SalesForce] Why Find Nearby App is not available in App Exchange

Seth Carstens has released some updates, which address the deprecation of the GoogleMaps API. His solution is some Visualforce and code external to the package, since it seems that Find Nearby Accounts is no longer actively supported as a package.

If you have the managed package version, you will need to uninstall the managed package and install the code from Seth's github repository, following the readme here: https://github.com/scarstens/FindNearby/

More information on the package update is here, under a thread called "About to be broken": https://appexchange.salesforce.com/listingDetail?listingId=a0N30000001gpWhEAI

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, you have to manually collect and include UDIDs of the devices you want to allow in your provisioning profile. This is generally what you do for beta testing an app prior to release.

Long story short, I think your focus on a private Appexchange listing is misplaced. The first question you should answer is whether you're going to list your app publicly on the Apple app store, and if so, why bother with Enterprise distributions?

Enterprise Distributions are intended for apps internal to a single company, as the name suggests. They are not intended for distributing a private app outside the Apple app store.

EDIT: So You'd Like To Brand An App (Or: How I Learned to Stop Worrying and Love the App Store)

Let's say you have an iOS app that should be branded individually for each of N customers.

A: Solo Enterprise

• How it works: You have one public Appexchange listing. Each customer installs your package into their org. You brand an iOS app for each customer, sign each app with your Enterprise profile, and send each customer an IPA to distribute to their users.
• How it ends: Apple revokes your Enterprise account for bypassing the app store.

B: You Have No Chance To Survive Collect Your UDIDs

• How it works: You have one public Appexchange listing. Each customer installs your package into their org. You brand an iOS app for each customer, build the app, and send them an unsigned binary. Each customer uses their own Apple Dev account to sign the app for their users (100 max devices) or their own Enterprise account (no device limit).
• How it ends: Ongoing pain with codesigning, perhaps the least enjoyable part of iOS development, and now you have to teach your customer how to do it? Additional time and $ for your customer. You buy some Excedrin.

C: Public

• How it works: You have one public Appexchange listing. Each customer installs your package into their org, and uses your VF or custom settings or whatever to set their own branding colors, images, and parameters. Your iOS app is listed on the public Apple app store. Anyone can install the app, but they cannot use it in an org without your package installed. When they sign in, the app reads your custom settings and applies the customer's brand. No Enterprise accounts involved.
• How it ends: $$$

You cannot use an Appexchange listing to host an IPA file. You need generic file storage (I've used S3 for this) and an installation page your users can access on their devices.

From your comments below, it sounds like you are headed towards Option A. It is irrelevant whether your Appexchange listing is public or private or how many listings you maintain; you will inevitably be shut down by Apple. In case it's not obvious, I think only one of the above options is worth your time. :)

Edit the second: There is one additional overwhelming advantage that is unique to Option C: all of your users receive updates simultaneously and can update without waiting on their admin to distribute your IPA to them... unless, of course, you are hosting the IPA file yourself and built your own app updating and notification mechanisms. (You did? STEP BACK FROM THE EDGE!!!)

Option C might be ruled out if you are using private APIs or engaging in certain other skullduggery that Apple frowns upon. (You did? STEP BACK FROM THE EDGE!!!)