On the Podcast This Week in Google episode 54 Jeff Jarvis, Leo Laporte, and Gina Trapani discussed the topic of verifying and testing that a third party mobile app works well and doesn't cause problems to the other applications already on the device. Jeff Jarvis brought up the idea of having an organization or company for testing and certifying applications, so that users would know they are safe to install, and having the app developer pay for the costs of this additional certification testing. Gina Trapani suggested it might be useful to have a Firewall to check which apps are accessing the network.
In response to Gina's commentary, I'd suggest looking at the F-Secure security suite mobile app that includes a Firewall, there are versions of the app for Symbian/S60 2nd ed/S60 3rd/5th edition, Android, and windows mobile.
The discussion got me thinking about the different ways mobile app signing and testing happens on Android, iPhone, and Symbian platforms. I would also include Blackberry but I'm less familiar with their platform and I'm not an E-mail fan, so I haven't used Blackberrys much.
Symbian App Signing
Allow me to take a momentary trip down memory lane, back to 2004/2005 before iPhone and Android existed when Nokia and S60/Symbian were arguably the top Smartphones in the mobile industry, a time when Sony Ericsson and Motorola were Nokia's main competitors. (Disclaimer: I started working at Nokia January 2005 and left the comany June of this year.)
This was a time when S60 2nd edition running ontop of Symbian was the primary smartphone platform used by Nokia. Even though the programming language of choice to develop on S60 2nd edition was the Symbian variation of C++ the platform was widely popular with developers, with many mobile apps ranging from games, photography apps, music players, to utilities, to audio editing/recording, etc.
In 2004/2005 Nokia was actively developing S60 3rd edition that would bring a pretty drastic change to the way applications could be installed and run on their smartphones. At the request of operators and with concern for users who were increasingly installing many applications, S60 3rd edition added a new Platform Security architecture. The Platform Security architecture required applications to be signed with a certificate in order to access the users data (such as Contacts in the Address Book, Calendar entries, etc.), it also required the application to be signed in order to use API calls that could cause a user to be charged, for example phone calls, SMS, and any network connections. This was a huge change from how applications on previous S60 platforms worked, where there was relatively little security mechanisms and 3rd party applications had the same access as pre-installed and system applications without any oversight.
The thousands of apps that were developed and ran on S60 2nd edition, could not be installed nor run on S60 3rd edition without being recompiled and modified specifically for S60 3rd edition, this was a so-called binary break in application compatibility. While platform updates are expected to change or add APIs at times, the Platform Security architecture along with the requirement of signing the apps created more work for developers. Further adding to the additional tasks that a developer needed to do to update their app from S60 2nd edition to run on S60 3rd edition, was the fact that the obtaining a certificate was not a straight forward process.
It's possible for a developer to self-sign their application, however that only permits access to some of the APIs and user data and a user will see a further pop up question asking them if they're sure they want to install this self-signed app. In order to have a more seamless installation or when an application needs further API access the developer must submit their application to Symbian to be tested.
In 2005 Nokia owned a large percent of Symbian, but Symbian was a seperate company. The developer of the app would have to pay Symbian in order to submit their app through the testing process. The Symbian signing tests included making sure the app install correctly on several different mobiles running the S60 platform, also that phone calls can be received, SMS can be received while the app is installed, If the app passes then it will be signed with a Symbian Certificate unique for the developer and then the signed app would be made available for the developer to download, if it fails the developer would be notified and would need to fix their app then resubmit it for retesting. After the developer finally has the Symbian signed app, they can sell it to users or offer it free on their website.
Remember that this was also the time before mobile application stores existed. Sure there were a couple websites where a developer could sell their app, but most developers hosted their app on their own website and the user had to search and find it on their own. This made for a situation where each developer had their own payment mechanisms, often with trial periods, and unlock codes for allowing the app to be used beyond the trial period.
The Symbian Signing process described above added overhead of cost and time to developing an app for S60 3rd edition for application developers. Thus many mobile developers delayed porting their app to S60 3rd edition and kept developing for S60 2nd edition where a majority of the userbase was anyway. Also some developers felt the openness of Symbian/S60 was lost due to Platform Security and chose to stop developing for S60 all together. This ended up hurting S60 3rd edition as a platform, the number of applications decreased for the platform and people who did buy S60 3rd edition devices didn't find the same breadth of applications. The situation got a little better after 1-2 years, but the S60 application market wasn't the same.
Symbian Signing is similar in concept to what Jeff Jarvis and Leo suggested could be good for Android, but as you can see things can go badly depending how it's implimented. Developers want to be able to develop their apps quickly, effeciently, and at a reasonable cost to themselves or their business.
Android App Signing
Jumping back to the present, Android also requires application signing. The way Android is setup an application not signed will not install or run on the platform. There are two types of certificates under Android, a debug certificate and a release certificate. A debug certificate is used when developing the app before it's ready to be released. Once the app is ready to be released it should be signed with a release certificate. The Android SDK tools assist in signing the application.
This means that with the Android SDK app signing is left up to the developer, and doesn't require submitting their application to a 3rd party company for testing or signing. This gives more control of app development to a developer and allows a developer to quickly update and push a new release of their app without having to wait a long period of time for testing by another company. Of course Playing devil's advocate it could also allow sloppy developer's to release more unstable apps on Android. Having a test certification company perform further testing on an app before making it available to users might make apps more stable or reliable for users but it would increase the cost and time overhead for a developer. Essentially Google is leaving the development, testing, and updating of apps entirely up to the app developer. For now I'd say Android users should be cautious of what they install, and to pay attention if you find the software responsiveness to become slower or find your mobile becoming more unstable then uninstall whichever app you recently installed, it will probably improve the problem. Hopefully Google will develop an App Marketplace in the future where it's easier to filter and find quality applications, than the current one.
iPhone App Signing
Now lets take a look at how Apple has implimented things. It is interesting to note that when the iPhone SDK was first announced, Steve Jobs specifically mentioned Nokia's implimentation of app signing, "Nokia, for example, is not allowing any applications to be loaded onto some of their newest phones unless they have a digital signature that can be traced back to a known developer." This is in reference to the Symbian Signing process.
Apple's implimentation is probably the most streamlined of the three. All apps for iPhone also have to be signed (with the exception of Jailbroken apps of course). There are are two types of certificates, one is a development certificate, the other is a release certificate, similar to Android's setup. The iPhone SDK handles the certificate signing during compilation. Apps signed with a development certificate can be run on actual iPhone devices, but the app can only be run on up to 100 iPhone devices at once. It was setup this way to allow developers to test their apps before releasing them, but not to use the development certificate as a distribution mechanism. In order to get a release certficate you must join the iPhone developer program that costs $100 per year. The developer program also includes testing the apps your submit and hosting any Apps you release, both free and paid.
With this setup Apple becomes the single point of contact for the developer, and while Apple's arbitary rejection of applications is bad, generally speaking they do a good job making sure the apps work for the users and won't cause problems on your phone.
I find it interesting the different strategies Apple, Google, and Nokia have taken. Even though Nokia were the first of the three to start the app signing requirement the process isn't as streamlined as Apple's process, and Google is clearly the most liberal in their process. Nokia has gradually improved the Symbian Signing process by introducing the Open-Signed certificate for apps that don't require API calls or user's data, and offering waivers for applications that are free where the developer has no income from them, such as apps released as Open Source that aren't being sold.