Yes, app stores for mobile platforms are a great thing, no doubt about it, and for most people that's how they discover and where they get all their apps and content from. An app store mono-culture, however, also has its dangers as the store owner can block apps he doesn't like. And some do… But I don't want to discuss policy but rather how alternatives work in practice.
On Symbian, apps can be installed from an sd-card or if received via Bluetooth or other means pretty much since its inception. An app store has only come recently as an addition and I have since used both methods to install applications. Android is also open and apps can also be installed from the SD card. Until now, I haven't tried this in practice so it was time to see for myself how that works.
For the purpose, I've used a self-written app (more about that in a future post) so I could experience first hand what a developer has to do to publish an application in an app store or otherwise. Android applications need to be signed by the developer with a private key that he generates himself, i.e. there is no certificate authority that authorizes a developer or the deployment of an application. The purpose of signing an app is to identify the author of an app but since there is no central certificate authority, that's a relative thing. Furthermore, the signature can be used to build a trust relationship between applications but I am not sure how and if that is used in practice. For details on the signing process see here.
The result of packaging and self-signing an application by the developer is a single ".apk" file that can then be put on an SD card by whatever means. The app is then installed with the help of a file explorer on the mobile device which comes pre-installed on Samsung based Android devices such as the Galaxy S for example. With a tap on the filename the app installer is launched which then requests the user to confirm the access rights requested by the app in the same way as if the app had been loaded from an app store.
Android enforces access rights for functionality that could incur cost such as making phone calls, sending messages, accessing the network, etc. and also for privacy related features such as accessing location information, accessing the phonebook, calendar, sd-card contents, etc. During the installation process the user is presented with the list of access rights the application requests so he gets an idea if the application requests more rights than it actually needs. If, for example, a calendar widget requests full location and network access that's more than a bit suspicious. If the user agrees to give the requested permissions the app is installed, otherwise the process is aborted.
If an application tries to use functions it doesn't have requested permission for during the installation process it dies a quick death once it tries to access those parts of the system. That means that the virtual machine terminates the execution of the app with an ugly error message as I experienced myself with the demo app I installed when I forgot to ask for permission to access location information.
For the user, all of this is transparent. All he needs to do to install the app is to put the ".apk" file on the sd card, use a file explorer to start the installation process and confirm the access right requests made by the app.