Getting to Market

Accredited Symbian
Developer is an industry-
standard qualification for
smartphone software
developers

The Accredited Symbian Developer examination

assesses the capabilities of candidates against a
curriculum of core knowledge. The curriculum
includes both theoretical and practical topics,
assessing both the understanding and application
of Symbian C++.

Each examination consists of an examinee being

asked a subset from a pool of contemporary
questions. The questions are weighted and each
examinee will be asked questions tailored to
the level of ability that they exhibit whilst
sitting the examination. Individuals that pass the
examination acquire the industry-recognised title
‘Accredited Symbian Developer’.

For more information visit

www.symbian.com/developer/academy and
www.majinate.com
Getting to Market
Getting to Market
part of the Using Symbian OS series
1st edition, 04/08
Published by:
Symbian Software Limited
2-6 Boundary Row
Southwark
London SE1 8HP
UK
www.symbian.com

Trademarks, copyright, disclaimer

‘Symbian’, ‘Symbian OS’ and other associated Symbian marks are all
trademarks of Symbian Software Ltd. Symbian acknowledges the trademark
rights of all third parties referred to in this material. © Copyright Symbian
Software Ltd 2008. All rights reserved. No part of this material may be
reproduced without the express written permission of Symbian Software Ltd.
Symbian Software Ltd makes no warranty or guarantee about the suitability
or accuracy of the information contained in this document. The information
contained in this document is for general information purposes only and
should not be used or relied upon for any other purpose whatsoever.

Compiled by: Reviewed by:

Colin Ward Roderick Burns
Antony Edwards
Managing Editor: Freddie Gjertsen
Ashlee Godwin Tanzim Husain
Phil Spencer
Jo Stichbury
Rupert Whitehead
Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
Commercial-Grade Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
Automated and Manual Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
Code Reviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
Code Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
Symbian Signed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
Protecting Your IP: How to Prevent Your Application
Being Resold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12
Internationalizing your Application . . . . . . . . . . . . . . . . . . . . . . . . . .15
Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
Channels to Market . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
Network Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
Building an Application for a Handset Manufacturer . . .19
Independent Software Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
Your Own Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
Content Aggregators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
Freeware, Shareware, and Open Source Software . . . . . .27
Making a Demo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
Internet Access Points (IAPs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
Promoting your Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
Working Together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
Symbian Partner Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
The Symbian OS Developer Community . . . . . . . . . . . . . . . . . .34
Developer Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
1

Introduction
So, you’ve worked hard for months and have written the
best ever Symbian OS application - let’s face it, we all
think our own software is the best ever! Now it’s time to
release it. Even if it’s feature complete and the defect
tracking system has been emptied of bugs and feature
requests, there’s still work to be done. It’s got to be
tough and crash proof. It’s got to be fast. It’s probably
got to be Symbian Signed. It’s got to have support
infrastructure. And most importantly of all, it’s got to
reach the widest audience possible.

In this booklet, we address these important post-

development issues, to help get your application solid,
signed, and out to the world.

The cumulative total number of applications for Symbian OS

released since Q1 2007
 2

Commercial-Grade Software
Automated and Manual Testing
On any platform, including Symbian OS, the three most
important properties of any piece of software are that it
never crashes, it performs well, and is responsive. But
how do you achieve this? Due to the nature of a
smartphone as a small handheld device with very specific
input mechanisms, it’s not always possible to fully stress
test an application automatically.

Generally speaking, crashes and undefined behavior are

more likely to happen when something goes wrong than
in the course of the daily successful use of an
application. So while it is important to test the most
common daily use cases, it is also important to try and
think of ways of creating real life problem scenarios and
to ensure that the application can handle them without
problems. For instance, if the application requires
network connectivity, what happens if that connectivity is
temporarily lost? Will the application gracefully handle
the loss of connectivity and recover, or will it crash or
behave in an odd manner?

There are two ways of trying to cover these eventualities:

• automated testing
• good old-fashioned manual system testing.

Automated tests can be classified into unit testing and

system testing.
3
Unit testing
This form of testing splits your application code into
discrete, standalone components. The components may
be a single class, for example, or a group of interrelated
classes with a defined set of very specific functionality.
As you write each component, you also create
accompanying test code that acts as a client to the
component. You can find an example of how to create a
basic test harness on the wiki page for this booklet, at
developer.symbian.com/getting_to_market_wikipage.

Testing should typically be performed as a series of small

checks to ensure that various functions provided by the
component can be called successfully. It should also try
to call these functions in such a way that will actually
fail. For instance, to test a component that provides
access to data files you could purposely pass in invalid
filenames, call Close() without calling Open(), try to
read records that don’t exist, and so on.

Automated unit tests also have the advantage that if you

add more code to the component at a later date, you can
run the tests again to ensure that your new code has not
inadvertently broken something, which is known as
regression testing.

System testing
As the name may suggest, system testing is about testing
all of the components working together. Just because the
unit tests pass doesn’t mean that there will not be
defects caused by unexpected interactions between
components.
 4
Unfortunately, automated system testing is not as easily
defined as unit testing. You may be able to write an
application that pulls in a number of components and
tests them working together. This is a great way of
testing the interactions between the components and,
like unit testing, it can be used to test for regressions
when you change your code.

However, it may be that writing system tests is as much

work as writing the original application, or even more! It
boils down to the size and complexity of the application,
the number of people on the team, and the amount of
time available. For small applications, some unit tests
and manual end user testing is enough. For larger
applications, the time involved in writing automated
system tests will pay off.

Manual testing
Whatever level of tests are written for automatic testing,
on a platform as user centric as a smartphone, old
fashioned manual application testing by real people is
ultimately the most important of all.

There is software available such as TestQuest Pro from

TestQuest (www.testquest.com) that can simulate this
manual testing by injecting events into the input stream.
This can be very helpful, but it suffers the drawback that
human beings do the most unexpected things when
using an application. You could write the most
comprehensive automated tests and extensively test the
application yourself manually, but as soon as you put the
smartphone in the hands of an uninitiated user, they will
immediately do something completely unexpected. For
instance, they could open a file, accidentally hit the
5
application launcher button, and then, while trying to get
back to your application, accidentally launch another
application. Suddenly your code crashes and you are left
bewildered because you were convinced it was solid.

Since crashes are most likely to happen when something

goes wrong, create test cases that make bad things
happen. The Symbian OS emulator has a facility for
emulating out-of-memory situations; its interface can be
accessed by hitting Ctrl+Alt+Shift+P on the PC while the
emulator is running. From this dialog, you can make the
emulator fail heap allocation attempts in the currently
running program. This can be deterministic (i.e., every nth
attempted allocation) or random, and can be useful for
finding allocation failures that are not handled properly.

However, it’s not just memory allocations that can fail,

and so this is only one type of test. Attempts to connect
to servers, to send messages, to open files, to load
resources, and so on, can all fail and/or leave. If they
do, how do you know that your class – and indeed the
entire application – is going to handle that situation
properly? The answer: you don’t! Whenever you finish
implementing a class, and it has passed the various
automatic tests that have been written for it and is
working on the phone, try conducting ‘forced failure
testing.’ This can be a fair bit of manual work, but the
results are well worth it.

‘Forced failure testing’ analyzes the class that has just

been written and then, in any function that can leave,
adds some temporary code to force it to leave (i.e., by
making a call to User::Leave()). You can compile the
temporary code, put it on the device, and run it. If a
 6
particular function can leave in three places, test the
application’s behavior when it does so at each of those
three points in the code. You should do this because it is
all too easy to misuse the cleanup stack, to forget to
reset variables, or to overlook the paths the code logic
takes when an error occurs, and so on. Unfortunately, we
sometimes consider the leave mechanism to be
something magical that resolves everything and handles
failures automatically. However, forced failure testing is
necessary to explore how the application will act in the
‘real world’ when a leave occurs.

Tools
If you have a budget to spend on tools for testing and
improving the quality of your code and your application,
then a code coverage tool is also worth consideration.
The Bullseye Coverage tool is ideal for generating metrics
that give you an idea of how much of your code has
been tested. It allows you to focus your testing effort and
to pinpoint areas that need review, for example, because
the test code has not covered every line of code. More
information is available at www.bullseye.com.

Code Reviews
Another way to confirm the quality of your code is to
perform static code analysis – otherwise known as a code
review. You can do this manually, of course, either by
checking it yourself or, preferably, by asking a colleague
or team mate to review the code and to give you
feedback. The Symbian Press Coding Standards booklet
(at developer.symbian.com/booklets) can be used as a
guideline when performing a code review.
7
If you prefer to automate static code analysis, there are
also some tools available – for instance, the Professional
and OEM Editions of Carbide.c++ v1.3 ship with a tool
called CodeScanner. Running CodeScanner on a project
generates a report of the areas where it considers there
may be problems, for example:
• methods that can leave but are not named with a
trailing ‘L’
• descriptor parameters that use pass by value rather
than pass by reference
• ‘worrying comments’ such as the words ‘hack’ or
‘to do.’

CodeScanner is rather like the Lint tool for C++, but

instead of checking for common C++ programming errors,
it looks for more specific Symbian C++ ‘gotchas’.

The automated source code analysis company Coverity

announced in 2007 that it would also be adding support
for Symbian C++ to its Prevent SQS static code analysis
tool. More information about Prevent SQS is available at
coverity.com/html/prod_prevent.html.

Code Profiling
Carbide.c++ Professional and OEM Editions ship with
Performance Investigator, which is a profiling tool for
analyzing the performance of applications running on S60
3rd Edition devices. The tool runs as the application
executes and determines which sections of code should be
optimized to improve performance, memory, CPU usage, or
power consumption. You can find out more about
Performance Investigator, and the other tools that Carbide.c++
ships with, from the product page on Forum Nokia, at
www.forum.nokia.com/main/resources/tools_and_sdks/carbide
_cpp.
 8
Usability
Make sure to put your application in the hands of other
people for usability testing, especially those who are less
technically inclined. The problem with having engineers
test applications is that an engineer is more likely to
understand how the application works, and to use the
application in just the way it was meant to be used.
This will not be the case with non-techies, so use them
as a testing resource! It’s a fine balance between writing
an application to do the right things and its usability –
and you need lots of different perspectives to help you
get it right.
9
An important thing to keep in mind when it comes to
usability is that there are many different styles of phone,
and you can’t assume anything about the form factor of
the phone on which your application will run. The
creators of the platform UIs running on Symbian OS (UIQ
and S60) have thought long and hard about usability.
Both interfaces address the issues associated with
running on multiple devices with different screen sizes,
input mechanisms, and key layouts.

There is always a temptation to ignore the UI guidelines

by thinking, ‘my application is special and the rules don’t
apply to me. I’ll make my application look consistent
across the platforms.’ Think very carefully before
succumbing to this belief, even though the reasoning
behind it is understandable. For some application types,
such as games, this approach does make sense, but for
other applications it is often more appropriate to follow
the usage guidelines for the various GUI components that
are supplied by the UI. You can find links to the S60
and UIQ guidelines on the wiki site for this booklet, at
developer.symbian.com/getting_to_market_wikipage.

By following the UI guidelines, you can ensure that your

application fits in visually and conceptually with other
applications on the device, and that it takes advantage
of the research done by the UI vendor regarding device
form factors, input methods, and general usability.
Remember that both UIQ and S60 phones can work in
portrait and landscape modes and that some phone
models can dynamically switch between these modes.
Symbian smartphones may be pen-based or keypad-
based, or both, and you need a strategy for how your
application will handle the differences. Make sure you
 10
test on a range of devices from each UI platform you are
targeting. For example, if you create an S60 application,
be sure to test it on both Nokia and Samsung devices.

Mobile games
As I mentioned above, there is one type of application
that is, by its very nature, going to be exempt from the
rule of adaptation to the platform UI: the mobile game.
Designing a 3D game to run on different devices is less
problematic than for 2D games, because 3D graphics are
scalable. Even so, handling portrait and landscape mode
may still be a challenge because of their very different
aspect ratios. 2D games by their nature are not scalable
and are therefore more susceptible to device differences.

Screen resolution affects 3D projection and view angle, as

shown for a portrait orientation (top) compared to the same
graphics for landscape orientation (below).
Game images from Snakes Subsonic, courtesy of Nokia,
copyright 2008
11
Some larger games companies take the extreme measure
of customizing the game for each target phone but this is
untenable for smaller companies. Anecdotal evidence
suggests that it is common for Java ME games to exist in
600 distinct variants or more, simply to take into account
all the permutations of language, input capabilities, and
screen sizes that are required to run on the different
devices in the marketplace.

All that is possible in this situation is to try and design a

game from the outset so that it can display more or less
of its playing area depending on the screen size, rather
than assuming particular dimensions. A scrolling platform
game, for instance, that works by displaying a tile-based
map, can vary the number of tiles it displays vertically
and horizontally without changing the game play
dynamic. However, a game that relies on static full-
screen bitmapped backdrops is not going to scale well to
different screen sizes.

Another aspect to consider when creating your own

system for a game is that, by avoiding the system’s input
paradigms and mapping actions directly onto keys, you
will have to be careful to ensure that those keys are
actually present on the device. For example, some UIQ
devices do not have four-way controllers, so you may
need to map the controller’s actions onto different keys,
such as 2 (up), 4 (left), 6 (right), and 8 (down), with 5
doubling as the central selection key.

There can also be slight key code variations between

manufacturers (and between the device and the
emulator), so don’t assume that the input code for each
key will be the same on all devices. Try to test on as
 12
many models as possible, and on devices from as many
manufacturers as possible, or provide the user with a
way to set their own choice of input keys.

Symbian Signed
Signing your application with Symbian Signed is an
important part of releasing software for Symbian phones.
There are different levels of signing, and which you
choose depends largely on the application itself.

At the simplest level, if your application does not use

any platform security capabilities, or only requires user-
grantable capabilities, you may decide not to use
Symbian Signed at all. Currently, user-grantable
capabilities allow ‘self-signing,’ which means that using
Symbian Signed is not essential for installation. However,
as soon as you write code that accesses more privileged
APIs, you’ll probably need platform security capabilities
that require you to sign your application with Symbian
Signed.

There are several levels of signing available, and so

signing an application can actually be quite an in depth
subject, far beyond the scope of a small booklet such as
this. Up-to-date information on Symbian Signed can be
found at www.symbiansigned.com, or in ‘A guide to
Symbian Signed,’ which can be downloaded from the
Symbian Signed website.
13
Protecting Your IP: How to Prevent Your Application
Being Resold
This is a complex problem, and there is no single or
instant solution to it. Different approaches are
appropriate for different applications and business
models. Sometimes the effort required to protect your
software may not be worth it, and it’s better just to
release your software and rely on people’s honesty.
Alternatively, try to come up with a business model
where copying the application is actually a good thing.
However, if you really do feel the need to prevent your
software from being freely copied, then there are a few
ways of going about it, but the important thing is to
make purchasing an application as simple as possible for
the user.

SMS Activation
One popular way to protect your software is to use an
activation SMS. The user sends a one-off SMS to a
particular SMS number, and an SMS is sent in reply to
activate the software. This can also be a handy way of
letting the user pay for the use of the software, by
setting up a premium SMS number.

It also has the advantage that if the user changes

phones, then they can resend the activation SMS to the
server, which can detect that the phone’s number is
already in its database and re-activate the application
without recharging the user.

However, even though this is a useful approach, it does

have some disadvantages:
• you need an SMS gateway, which is going to cost
money to set up
 14
• by setting up an SMS gateway, you may be
restricting the number of countries a user can
register from
• if the user changes phones and phone numbers, the
re-activation will not work and the user will have to
purchase a new copy of the application.

Using an Authorization Server

Another way of authorizing an application is to require it
to connect to a server, either from code within the
application, or by launching the phone’s web browser
with a URI. You can then download a token associated
with the phone’s IMEI that authorizes the application for
use.

The problem with this is that you need to set up a server

with a database that can store a list of IMEIs and record
the fact that they are registered. It also depends on the
user’s phone having Internet access, which cannot be
guaranteed. In addition, if the user gets a new phone,
then he or she won’t be able to download the application
from the server again, since it will consider the new
phone (with its different IMEI) to belong to a new
customer.

Selling the Application Over the Internet

This approach requires users to use a PC to log on to a
website to purchase the application. This poses a
difficulty in that you need to find a way of associating an
application bought on a PC with a particular phone.
A good way of doing this is by using the IMEI of the
phone. However, users don’t necessarily know about
IMEIs, and it’s not very user friendly to expect them to
type in this long, arcane number, ascertained by first
15
typing in the *#06# code as they would a phone number.
Furthermore, you cannot guarantee that the user will
know how to install the SIS file from their PC once they
have it. It also restricts how you distribute your
application.

Unfortunately, all methods of registering applications for

mobile phones have their drawbacks, and it is up to you
as an author to choose the method that best fits your
software.

Internationalizing your Application

Internationalization is by no means mandatory, and if you
target your application at just one country where just one
language is spoken, then it might be unnecessary.
However, when targeting multiple markets, Symbian OS
has powerful support for internationalization.

There is an easy method for creating SIS files that

support multiple languages. One language (usually
English) will be used as the default language, but other
languages can be included in the SIS file in the form of
resource files. Upon installation, if the phone is set to a
language other than English then the appropriate non-
English resources will be installed and the application will
operate in that language. If no resource file is found that
matches the language that the phone is set to, then the
default English resource file will be installed.

Internationalization generates software variants in

multiple languages from a single set of source files.
Typically, you’ll aim to have a core of code that contains
all the functionality of your application and doesn’t
change regardless of the language. A second part
 16
contains the changing content, such as text strings
displayed in the UI.

Not only do you need to consider the differences in

language when you internationalize your application, but
you’ll also have to consider variations in writing systems,
regional differences (such as layout of numbers, time, or
measurements), and specific customizations. Symbian OS
provides support for the localization of dates, numbers,
currency, and so on, with the useful TLocale class.
You can find out more from the Symbian Developer
Library of the SDK (look for the Locale Settings guide in
the Base section of the Symbian OS Guide).

Distribution
Channels to Market
Like so many things about smartphone programming,
there are no firm rules for getting your application to
market. As a developer, you need to think about the
nature of your application, the end user of that
application, and your customer, which may be the end
user or it may be a network operator or another large
company.

Network Operators
Using network operators as a channel is a good approach
as they have a large customer base, often brand devices
with their own signature applications, and also offer
other applications for download from their portals.
Working with the network operators does have its
downsides though:
17
• Network operators are notorious for taking a long
time to hammer out deals; expect 18 months from
when you first approach them to when your
application gets onto a portal, although this will vary
depending on the operator.
• Application signing and testing by an independent
test house usually becomes mandatory, and this
means additional work, which can be expensive,
especially for small companies.
• If you decide to use this method exclusively, then it
means that you are limiting your audience, because if
a user finds out about your application and isn’t with
one of the network operators you have collaborated
with, then they won’t be able to obtain it.
• You will probably have to negotiate a deal with multiple
operators, and may find that you have to renegotiate
with the same operators in different countries.

Ultimately, using operators is a good approach, but be

prepared for lots of negotiating and the fact that you will
be one of many companies trying to convince them that
your application is the best.

Network operators look for applications that meet their own

propositions, and one key goal is to promote data
consumption. If your application requires the user to
download even small amounts of data on a regular basis,
the network operators will find it far more interesting than
one that never requires the user to make a data connection.

You can find out more about the other 'hot' areas that
operators are keen to promote by listening for key
messages whenever the operators speak at developer
events (more about these in The Symbian OS Developer
 18
Community section later in this booklet), or when they
issue press releases or other material to help analysts
‘sync up.’

Some network operators run specific events that provide

the opportunity for you to promote your application to
them. At such events you get to present your product to
representatives of the company in a very short space of
time, to explain why it should be made available as one
of their signature applications, or for download from their
portal. If you can’t get to such an event, it’s worth
joining partnering programs, such as 3neXt from
Hutchinson (next.three.com/suggest/developer.aspx),
Orange Partner (www.orangepartner.com), or AT&T
devCentral (developer.att.com).

The operators research the market and if your

applications are receiving good feedback from users, or
the operators have access to download statistics and see
that you have a popular product, you may be invited into
a tendering process in order to be selected to supply
applications to them.

However you get noticed, once you have negotiated the

deal with the network operator, you are probably
guaranteed revenue from each copy of the application
that is sold. The downside of this approach is that the
operators will take a certain percentage of the revenue
for themselves, although this amount will vary from
operator to operator.

Further details of application developer programs can be

found on the wiki site for this booklet, at
developer.symbian.com/getting_to_market_wikipage.
19
Building an Application for a Handset Manufacturer
Like working with operators, this is another approach
that can bring your application to the attention of a large
number of people. Also like working with operators, it’s
hard work.

The ultimate prize here is having your application

included in the ROM of a phone. This will mean that you
have a potential audience of millions. However, it’s a
tough thing to do because being embedded in ROM
means using ROM space, and this means cost to the
phone manufacturer. It also results in extremely high
visibility on the phone, and so the application has to be
exceptional. Unless you are a comparatively serious
player in the industry, with a unique application, it is
going to be hard to convince a manufacturer to put your
code in their ROM.

If you do manage to do this, this may lead to further

time-consuming activities and problems:
• The phone manufacturer will be very fussy about
application quality, and you can expect to go to a lot
of effort to ensure it.
• You will often have to work with pre-production
hardware which can be challenging, and which
presents a number of logistical problems. For
example, in the final stages of the project, you may
have to spend a significant amount of time working
on the manufacturer’s site.
• You may have to send off builds of your code for the
manufacturer to build into ROM and test, and all you
get back is the results, which can make debugging
very difficult.
 20
• On top of all of this, the manufacturer will enforce
extremely strict quality controls that mean you can
spend an awful lot of time following processes
pertaining to testing and documentation.

A more realistic approach is to get included on the CD-

ROM that is distributed with mobile phones. Because
these applications are optional and are on a CD-ROM, they
are less risk to the manufacturer and do not have the
problems of using ROM space. Although it seems far less
impressive to be on a separate, optional CD-ROM, it’s still
quite a big win. Remember that smartphone users are
often enthusiastic about what ‘freebies’ are on the CD-ROM
that comes with their phone. You will still have to do the
work to convince the manufacturer to take your application
and, of course, application signing and testing by an
independent testing house will be mandatory.

Just as with negotiating a deal with network operators,

the effort is worthwhile because it creates the potential
to ship a very large number of copies of your application.
This is a curious approach in a way because the number
of copies of your application shipped will depend more
on the popularity of the phone it is shipping with than
the popularity of your application! It is important,
therefore, to consider the phone with which the
application will ship, its importance to the manufacturer,
and therefore how well it will sell, as this will affect how
you negotiate the license. You can either try to negotiate
for a royalty per unit or for a one off payment. Both the
popularity of the phone and the manufacturer you are
dealing with will ultimately affect which option is chosen.
21
Symbian’s partner program, discussed later in this
booklet, may be a good place to begin networking and
to gain introductions and contacts within the network
operators and phone manufacturers. Often, the
manufacturers have their own partner programs, such as
Forum Nokia Launchpad (pro.forum.nokia.com) or
Motorola’s MOTODEV (developer.motorola.com). These are
good places to promote yourself and to find out what
others are working on.

Independent Software Channels

Some mobile application sales channels are independent
of network operators. These channels sometimes have
less traffic than the operator channels, but application
developers still find they offer potential for application
distribution.

There are a number of channels that provide mobile

applications; some do so as part of their wider offering,
while others specialize in them. Examples include
Cellmania, Handango, Handmark, MobiHand, Motricity,
and SymbianWare.

The channels may offer a mobile website for buyers to

browse, allowing the purchase of applications by direct
download over the air (OTA), with payment made by
means of sending a premium-rate SMS or the more
traditional credit card approach. Other vendors may offer
an additional website for purchasing applications over
the Internet (OTI) onto a PC and then transferring the
application to the phone and installing it.

However, some network operators may lock down their

phones against what they call ‘side loading,’ which
 22
means that applications cannot be installed except by
direct download to the phone. The lock down ensures
that the operator retains some profit from application
installation, even when it is not purchased from one of
their portals. (Some network operators go further still
and prevent the phones they distribute from making
purchases except from their portals.) Thankfully, this is
not currently a widespread practice, though it is very
common in Japan.

Some phone manufacturers also provide sales channels,

such as the Nokia Software Market. These channels are a
way for manufacturers to make software available and
encourage the uptake of their handsets. Rather than
decide themselves what these sites provide, the channels
often use the services of a content aggregator, such as
Jamba! (also known as Jamster in English-speaking
regions), to put together the content offered.

The Nokia Software Market is available for users to buy

applications OTI (www.softwaremarket.nokia.com) or
directly on the phone using an application called Nokia
Catalogs. The Catalogs application is a client on the
Nokia Content Discoverer system and is available for S60
smartphones, allowing users to browse the applications
available online using their phones, and to download and
install them. The application supports both the
downloading of demo applications and full commercial
versions, and allows delivery of graphics, themes and
ring tones, Java ME applications, native Symbian C++
applications, videos, music, and content developed using
Flash technology. Similar concepts exist for UIQ phones,
many involving the same channels as those used by the
Nokia service.
23

Nokia Software Market: www.softwaremarket.nokia.com

Independent channels are usually the preferred route to

market for application developers working alone or in
small companies, because it is easier to place an
application for sale with the channel than to forge a
relationship with a network operator or content aggregator.

The channel will take a percentage of each sale of the

application, but this is typically less than a network
operator or aggregator, and the channel will allow you to
set the price of the application yourself. For example, the
Nokia Software Market takes 40% of the sales price you
set, with revenue paid every quarter. For more
information about working with the Nokia Software
Market and Catalogs application, please see
www.forum.nokia.com/main/software_market, or consult
the Nokia Sales Channels section on the main Forum
Nokia developer site at www.forum.nokia.com.
 24
The channels often re-skin their application catalogs for
operators, so by distributing through the independent
software channel, you can find your software gains more
visibility by operators and may then be easily distributed
in other re-branded channels.

Your Own Channel

This is an approach to distribution that can potentially be
a lot of work. The main thing here is that you are going
to have to set up the infrastructure for distribution. A
website and download mechanism (preferably with two
sets of web pages - one for use on a mobile phone and
one for use on a PC) are easy enough, but setting up a
credit card or another payment system will take some
more work. Not only this, but if your company is small
and not well known - and this is often the case in the
world of Independent Software Vendors (ISVs) - then
people are not necessarily going to trust you with their
credit card details. In this case, it may be a good idea
to outsource taking payments to a well-known and
trustworthy company that specializes in this. Users will
feel far more confident using a service such as PayPal
than a small, unknown company.

The big advantage of this approach is that you get to

keep closer to 100% of the download price for yourself.

Some good examples of mobile game companies who

have set up their own channels include ZingMagic
(www.zingmagic.com) and Astraware (www.astraware.com).
You can find a link to a presentation from Astraware,
about how to engage with your customer through your
own online portal, on the wiki page for this booklet
(developer.symbian.com/getting_to_market_wikipage).
25
Content Aggregators
Content aggregators are specialists at gathering content,
such as mobile applications, video, and ring tones. The
content is acquired from suppliers such as games
publishers or independent channels, and distributed by
the content aggregators to their sales channels. Content
aggregators provide an easy way for businesses to source
downloadable material without having to seek it out and
build a relationship with each supplier.

Working with content aggregators is a good approach for

smaller ISVs that do not have the budget for approaching
operators and manufacturers. It has many advantages.
Depending on the aggregator, they may not have the
strict signing and testing requirements of the operators
and manufacturers. They also won’t take so much
convincing to promote your application. After all, the
more applications they have available, the more money
they stand to make!

As specialists in application distribution, they have the

required infrastructure and you can use this to your
advantage. The ability for people to pay for and
download your application is taken care of for you.
There is also the advantage that your application has a
large audience, even without any advertising.
Enthusiastic smartphone users will surf to these sites to
see what interesting applications have been launched
recently.
 26

Handango (www.handango.com) acts as a content aggregator as

well as an independent software channel

The disadvantage of using a content aggregator is that,

depending on your application, it may be lost in the
crowd. A user will come to an aggregator and do a
search for a particular type of application (for example,
an email client) and as well as your application appearing
in the search results, so do a number of applications
created by your competitors. The user is likely to choose
one at random. To make it stand out, you have to
differentiate your application from its competitors, and I
recommend the following approaches:
• Give the user lots of information about the
application. At the minimum, a website linked from
the application download page on the aggregator is
a must.
• Have lots of screenshots to show that your application
looks (and is) better than your competitors’.
27
• Use a name that clearly defines what your
application does, rather than a more esoteric one,
and use a clear description of your application that
will ensure that a user finds it when searching.

This approach is still somewhat hit-and-miss because the

number of people that will download and buy your
application is an unknown. Will people even be looking
for your application? Will they know it exists? If it is
innovative enough, you may be able to negotiate for it to
be displayed on the front page of the aggregator’s site.
Ultimately, the amount you will earn from this approach
depends on the number of people who download and
buy your application. The download price will usually be
split between you and the aggregator.

Forum Nokia publishes a comprehensive list of mobile

content aggregators at
www.forum.nokia.com/main/go_to_market/aggregators.html.

Freeware, Shareware, and Open Source Software

You can release freeware applications as self-signed SIS
files if the capabilities your application requires are in the
‘User Grantable’ set or if your application does not use
any capabilities at all (see
wiki.forum.nokia.com/index.php/Capabilities for more
information).

However, those applications that require more advanced

capabilities must be Symbian Signed. If you decide to
distribute your freeware and need to get it Symbian
Signed, you will need to purchase a Publisher ID and
follow the Express Signed or Certified Signed route.
Alternatively, you can distribute your application using
 28
‘test range’ UIDs and allow users to sign the file using
Open Signed Online through the Symbian Signed website.

A breakdown by sales type of the applications for use on

Symbian OS smartphones, from Q1 2007 to Q1 2008

Making a Demo
You may decide to make a demo of your application
available, because some users may not want to buy an
application that they have not tried. Preferably, the
demo application should be unlocked with a code, to
make it easier for users to purchase and run the full
application. Otherwise, they would have to go to the
effort of paying for it and then downloading the full
version of the application, which may also incur an extra
data charge if they do it OTA.

How to limit the demo is up to personal preference and

the type of application, and there are various options
available. You can, for example:
29
• give it a time limit, either limiting its use to a certain
number of minutes per use, or a certain number of
days from installation
• limit the number of times it can be executed
• reduce the functionality of the application, for
example, by preventing the player from saving the
level they have reached in a game.

Whichever method you choose, ensure that you give the

user a decent taste of the application. If the demo is too
restrictive and doesn’t give the user enough time to
explore the application, it won’t hook them in and they
won’t buy it. At the same time, if you give them too
much time to use it, then it isn’t worth their time to buy
the full version.

Support
One thing that all of the distribution methods have in
common is that you are going to have to set up some
sort of support channel. If you are lucky and have a deal
with a large company they may handle this, especially if
they have licensed your application and branded it
themselves. Even then, they will often insist that you
have a support site. Again, this means infrastructure - a
web server with some sort of forum software running on
it is a good start, and definitely a
support@yourcompanyname.com email address that is
checked regularly and is responsive.

Whatever your application, users are varied and have a

wide range of skill levels. Some will download your
application and won’t know how to get it onto their
 30
phone. Others will find defects and will need to be able
to tell someone in your company about them - and they
will expect something to be done about them!

This brings us to the next point - make sure that you

have someone on hand with good communication skills
that can monitor the forums or the support email address
and ensure that users are helped out in a timely fashion.
There is nothing more frustrating than posting a message
on a company’s support forums and not getting an
answer. You can benefit from this interaction with your
users. When users report a defect and you fix it, your
application benefits; it’s like having an enormous Q&A
department at your disposal.

Internet Access Points (IAPs)

There is one particularly painful area of support that is
specific to the smartphone industry and it is difficult to
address it, although thankfully it doesn’t apply to all
applications! It applies only to those that require access
to the network, and it concerns IAPs.

IAPs have been set up by the smartphone industry so that

you can have WAP access points, where you can only
access servers on port 80 (often through a WAP gateway),
and generic TCP/IP access points, where you can access
servers on any port. When a user gets a new phone, one,
both, or neither of these IAPs will be set up. Each
network operator will have a different mechanism for
configuring them and, on top of that, they are often given
names that do not necessarily reflect their purpose. Even
an expert can have trouble setting up their IAPs, and an
average user could well find it virtually impossible.
31
Even worse, as a company based in one country, you
may get support emails from users in a completely
different country who need help with their IAPs. Have you
ever tried figuring out how to get working IAP details for
TCP/IP in a northern Indian state, or a country in South
America? It’s not easy! The support person will need to
be someone with patience, and you can expect quite a
few emails sent in either direction before the user’s IAP is
up and running.

Network operators are addressing these problems and

often a phone will configure itself when you insert a new
SIM card. However, you will almost inevitably encounter
this problem at some point if your application needs to
access the network.

Promoting your Application

This really is important - how will people use your
application if they don’t know that it exists? Like many
things in the mobile phone industry, there isn’t a hard
and fast answer to this, and how you approach this will
depend on a number of factors. How big is your
company? Do you have partners? Do you have an
advertising budget? Is the application complex or
simple? Who is the target?

Many ISVs developing for Symbian OS are smaller

companies partnering with larger companies. This is a
nice way of working because you can concentrate on the
application and, once it is delivered to the partner
company, they will take care of its promotion. Even
when using this approach though, it’s good to write a
 32
press release. Because the smartphone industry is young
and exciting, news about an interesting software release
will travel fast, and enthusiastic websites will do some of
the hard work for you!

Setting up an appropriately sized stall at an industry

tradeshow such as Mobile World Congress or the
Symbian Smartphone Show is another way of getting
some attention for your application. People from all
parts of the industry will come by, ask you questions,
and play with your application. If it’s good, word will get
out.

Another way of using the industry’s enthusiasm is to

send press releases to the various Symbian news sites,
such as developer.symbian.com,
www.allaboutsymbian.com, www.my-symbian.com, and
www.symbianone.com. These sites are always looking
for exciting new applications and news on Symbian to
post on their front page and to promote in their
newsletters. If you have an advertising budget, then
taking out a banner ad on these sites or ads on Google
is another approach.
33

SymbianOne: www.symbianone.com

Working Together
Symbian Partner Network
Strong relationships can deliver strong results. The
Symbian Partner Network comprises the top technology
innovators across the world and provides exclusive
access to the resources and tools necessary for the
development, sales, and marketing of solutions on
Symbian OS. The program is designed to deliver
maximum success to both Symbian OS licensees and
members of the Partner Network. Members of the
program benefit from:

• Symbian OS Binary Access Kit

• access to SDN++ (our world-class developer portal)
• exclusive use of the Symbian Partner logo
 34
• their company profile made available on the Symbian
Partner Network Directory
• exclusive webcasts and roadmap information
• exclusive events, for example, the annual Symbian
Partner Event, regional showcases, and licensee-
focused events
• exclusive discounts, for example, for Symbian Press
products and the Symbian Smartphone Show
• access to demo codes
• access to Symbian technical support services from
the Symbian 1:1 team
• co-marketing opportunities, where appropriate.

The Symbian Partner Network provides all of the tools

and resources to enable you to develop and market
commercial applications using the BAK and Symbian OS
APIs.

Access to the Symbian OS Development Kit, which

contains Symbian OS source code and advanced access
to new features, is only available to Symbian Partner
Network members. In addition, Symbian Partner Network
members have exclusive access to Symbian’s technology
validation program, Symbian Ready.

For more information about partnering with Symbian visit:

www.symbian.com/partner.

The Symbian OS Developer Community

Symbian OS Developer Community websites are a very
important resource, both from a technical programming
point of view and as a way of making your presence
known in the developer community. Sign up for the
Symbian Developer Network at developer.symbian.com
35
and - depending on your target smartphone platform -
register with the Forum Nokia, MOTODEV, Sony Ericsson
Developer World, and UIQ Developer Community websites
(you can find links to each of them on the Symbian
Developer Network).

Most of the developer communities have newsletters, so

sign up for these as well to ensure that you are informed
of upcoming trade shows and developer days - attending
these is vital to getting known and involved within the
community. They are a great way of meeting customers
and your peers, and of getting contacts within
manufacturers.

If you are bright and enthusiastic then you will quickly

find yourself meeting, and being noticed by, the right
people. In the mobile industry, support comes from large
companies in informal ways just as much as from the
more formal approaches, so it pays to get yourself
known. Trade shows and developer days can be a fun
social event as well, often with free food and drink. After
all, developers make a big contribution to the popularity
of Symbian smartphones, so we want to woo them!

If you need to solve a problem, there are community

forums to post on and additional routes to finding out
what you need by using direct technical support. The
latter generally tends to cost money, and for a small
business is often considered too expensive to use
frequently.

The biggest benefit to these is that they are great time

savers. When you have a problem and post a message
on a forum, then it is really luck as much as anything
 36
whether you receive an answer. If you use paid technical
support, there are guaranteed response times, and
guaranteed answers. Your support engineer will be a
specialist who has access to everyone within the
organization, so no matter how difficult your problem,
they will be able to ask the right questions of the right
people and get you an answer.
37

Developer Resources
Symbian Developer Network
developer.symbian.com

Symbian Developer Network newsletter

developer.symbian.com/register

Symbian OS Tools Providers

developer.symbian.com/main/tools

Forum Nokia
forum.nokia.com

MOTODEV
developer.motorola.com

Sony Ericsson Developer World

developer.sonyericsson.com

Sun Microsystems Developer Services

developer.java.sun.com

UIQ Developer Community

developer.uiq.com
 New books from

Games on Symbian OS: A Handbook for Mobile Development

This book forms part of the
Technology Series from Symbian
Press. It describes the key aspects of
the mobile games marketplace, with
particular emphasis on creating
games for smartphones based on
Symbian OS v9.x.

Developing Software for Symbian OS, Second Edition

This second edition of Developing
Software for Symbian OS helps software
developers new to Symbian OS to
create smartphone applications. The
original book has been updated for
Symbian OS v9 and now includes a new
chapter on application signing and
platform security, and updates
throughout for Symbian OS v9 and
changes to the development
environment.

Symbian Press: developer.symbian.com/press

 New books from

Symbian OS Communications
Programming, Second Edition
Targeting Symbian OS v9.1 and v9.2,
Symbian OS Communications
Programming - Second Edition will
introduce you to the major
communications functionality in
Symbian OS and demonstrates how
to perform common tasks in each
area.

Symbian OS C++ for Mobile Phones, Volume 3

This book will help you to become an
effective Symbian OS developer, and
will give you a deep understanding of
the fundamental principles upon
which Symbian OS is based.

Symbian Press: developer.symbian.com/press

 Books also from

The Symbian OS Architecture Sourcebook

This book conducts a rapid tour of
the architecture of Symbian OS and
provides an introduction to the key
ideas of object orientation (OO) in
software, with a detailed exploration
of the architecture of Symbian OS.

S60 Programming
Fully up to date for Symbian OS v9
and S60 3rd Edition, S60
Programming is an essential
foundation to developing software for
Symbian OS.
This practical book is based on the
authors’ experiences in developing
and teaching an academic course on
Symbian software development.

Symbian Press: developer.symbian.com/press

 Books also from

For all Symbian C++ developers:

Symbian OS C++ for Mobile Phones – Volume 1
by Richard Harrison
Symbian OS C++ for Mobile Phones – Volume 2
by Richard Harrison
Symbian OS Explained
by Jo Stichbury
Symbian OS Internals
by Jane Sales
Symbian OS Platform Security
by Craig Heath
Smartphone Operating System Concepts with Symbian OS
by Mike Jipping
Accredited Symbian Developer Primer
by Jo Stichbury & Mark Jacobs
 Booklets also from

Published Booklets
Coding Standards
Coding Tips
Performance Tips
Getting Started
Java ME on Symbian OS
P.I.P.S
Carbide.c++ v1.3
Data Sharing Tips
Essential S60 - Developers' Guide
Essential UIQ - Getting Started
Ready for ROM

Translated booklets available in:

Chinese Spanish
Japanese Russian
Korean
Getting to Market
Why? What? Where? How?

In this booklet, we address the most

important post-development issues (such as
preparing your software for commercial
release, distribution, and promoting your
application) to help get your application
solid, signed, and out to the world.

Getting to Market is part of the Using

Symbian OS series, designed to provide
information in a handy format to Symbian OS
developers.

developer.symbian.com/books