March 7, 2007
The Issue p. 2
Summary of Responses p. 2
Techdirt Analyst Recommendations p. 4
Insight Community Responses pp. 5-15
For additional insight from the Techdirt Insight Community,
please contact Techdirt at http://www.insightcommunity.com or 888.930.9272
T h e IS S u e
Outline A Strategy For Developing A Mobile Application
Developing applications for the mobile world is incredibly tricky. Unlike the PC world, where the choices
are pretty obvious, the complexity level for mobiles is exponentially more difficult. You basically take car-
riers multiplied by OEMs/handset vendors multiplied by operating systems multiplied by development
platforms to set the base level of complexity. Add to that the rapid churn rate of users, and it becomes even
So, for a company that’s developing mobile applications, and wants to maximize coverage while minimiz-
ing integration costs, what is the best strategy? We recognize that it may be different for enterprise apps
and consumer apps -- but are interested in both areas, so please give thoughts on both markets. Feel free
to think outside the box, but hopefully the answers are practical. As a secondary question, if the strategy is
to attack one platform at a time, what sequence of carriers/platforms/vendors makes the most sense, for
each of the consumer and enterprise markets?
Su M M Ary o f re S p o n S e S
One thing that became very clear in the Insights pro- strategy for the application would be. While this may
vided by the Techdirt Insight Community is that this is not seem directly relevant to development, it is key
a really hard problem -- one that many of the experts due to the nature of the market. If you cannot establish
had experienced first hand. The group, however, did certain key marketing relationships, then the develop-
have many practical thoughts. ment strategy may need to change drastically. While
it is considered a pain, getting your application “on
The first could be summarized as looking for the path deck” from big-name wireless carriers is definitely a
of least resistance. Many noted that it helped to look compelling strategy, if you are targeting the consumer
for some kind of “least common denominator” for market. Our Community makes it clear that this is no
moving forward, with some going all the way down easy task, and may require either exceptionally talent-
to the level of simply offering an application via IVR, ed sales people or a multi-pronged approach targeting
SMS or WAP. Taking a step up from there, many peo- a variety of carriers, while still preparing to prove out
ple suggested focusing on Java as the platform of least the application off-deck. If you must go off-deck with
resistance. No one really did so enthusiastically, given a consumer application, then they recommend part-
the many problems associated with Java, particularly nering with one of the popular aggregators, such as
the inconsistency of its implementation among hand- Handango, and also preparing to spend a significant
set vendors, which undermines the “write once, run amount (both in terms of money and effort) on mar-
everywhere” tagline -- but of all the choices it often keting. For an enterprise application, other potentially
has the least problems. Following that, the most com- easier sales channels exist, such as selling directly to
mon suggestions were some combination of Symbian, corporate IT departments, or through resellers.
BREW or Windows Mobile -- though which one often
depended on the type of application in question, as A third issue that plays into the decision making is tar-
well as the targeted location. This highlights the impor- get location. Many of the respondents focused mainly
tance of spending time on defining the requirements on a go-to-market US strategy, and noted that things
for your application, carefully considering the target changed if you were more focused on a European strat-
market, and determining how simple an application egy -- where Symbian dominates. One of our bloggers
can support your core functionality while delivering it pointed us to a marketshare chart (Figure 1) which was
with an acceptable user interface. created by Symbian, so there’s a bit of bias -- and it also
normalizes the population of each region, which may
A second important consideration in choosing a devel- be distorting.
opment strategy is what the corresponding marketing
Techdirt Insight Community — Mobile Application Development Strategies, March 2007 2
Fig. 1: Smartphone OS Market Share, 2006.
The final major concern brought up by our community There were two additional suggestions from our com-
was what additional features of a handset your appli- munity that could prove useful. One was to focus on
cation needed to access. If it doesn’t require access to developing the core functionality in-house, but then
more detailed systems (3D graphics was named a few licensing it out to others to develop more detailed sys-
times), then there will be fewer problems. tems and/or porting it to other platforms. A related
suggestion was to open up your application, either ag-
The end result is that there really aren’t “easy” answers gressively by going open source and hoping that others
to the problems facing mobile application developers will port to additional applications, or while retaining
-- and, it seems that the best strategy may be a multi- control by simply opening up certain aspects to allow
faceted approach. Depending on the target markets, others to develop hooks or tools to allow you to more
it’s advisable to focus on platforms that quickly give quickly tackle additional markets and platforms.
you more bang for your buck (Java mostly; Symbian
if focusing outside of the US). Following that, what Unfortunately, there doesn’t appear to be any kind of
shines through all the discussion is that partnerships silver bullet, but a phased approach that looks for a
are key. Finding the right partners, whether they’re few different paths of little (if not least) resistance, fol-
the mobile operators, marketing partners or even de- lowed by iteration as the market adjusts, seem to be
velopment partners who can help port your app for the strategies recommended by nearly all of our Com-
you become key considerations. munity members who took part.
Techdirt Insight Community — Mobile Application Development Strategies, March 2007 3
TechDIrT A nA lyS T re co M Me n D AT Io nS
One of the main problems our Community faced in portant.
providing direct recommendations to this insight was
that beyond just the complexity described in the ques- On the enterprise side, it makes less sense to leverage
tion, the many different types of potential applications those connections, but to focus on developing your ap-
in which the company posing the issue might be in- plication with a partner like RIM -- who dominates the
terested presented yet another dimension of complex- business market within the US – so it runs well on their
ity to the equation. Had the community known more BlackBerry devices. Successfully proving the applica-
about the application in question, the strategies would tion on the enterprise side with RIM will have others
have been more specific. in the corporate space banging down your door to help
port your application to their platforms.
Knowing more about what you are trying to achieve
ourselves, we can provide a few more specific recom- Finally, we recommend watching a few technologies
mendations. The key remains exactly what was dis- very closely, that while still early in development, may
cussed above. Nearly all of the technical design choic- make the process much easier in the future. Things
es depend heavily on the go-to-market strategy for the like Flash Lite and Opera’s widgets could provide a
application. The more well-defined that is ahead of much simpler path to more widespread compatibility
time, the clearer a development path becomes. with minimal development time, though they’re gen-
erally aimed at web-based applications. Looking even
Given your existing relationships and access to certain further out, there are some new players in the space,
mobile operators worldwide, for consumer focused such as DartDevices, who have a compelling “virtual
apps, it’s going to make a lot of sense to leverage those layer/virtual terminal” approach to mobile application
relationships as much as possible -- obviously for development. Its system not only allows you to run a
things like making sure your application is included single app on many different devices, but also to access
on-deck, but even for development help as well. Even apps found on one device from any other connected
using your core system, you should work with the op- device. However, the company is early on in develop-
erators so that they can customize the application to ment and faces the same problem you do in getting its
work with the various platforms and handsets they platform adopted more widely first.
support. This will be essential, as it’s likely on many
low-end phones, developing an embedded version of Overall, this is not an easy problem, but focusing on
the application will be necessary, since a Java version the go-to-market strategy first, followed by leveraging
wouldn’t be allowed to access enough of the handset’s existing relationships with key partners, while moni-
functionality to make the application work, or be use- toring some new developments, appears to be the most
ful. Providing a thorough developers’ kit will be im- likely path to success.
Techdirt Insight Community — Mobile Application Development Strategies, March 2007 4
In SIgh T co M Mu n I T y r e S p o nS e S
response 1 Blogger: hiteck
Before you devise a strategy for building a mobile ap- example, for a business app, evolve your application
plication, here are some observations of the mobile with Blackberry early adopters before you certify it on
world that can influence your approach: other platforms.
If support for multiple platforms is unavoidable, then
• Standards are not your panacea for interoper- use Java, but keep in mind that different phones and
ability. The mobile world is filled with confusing stan- models have varying degrees of Java support. There is
dards, protocols and operating systems. Even within enough expert knowledge published on the web that
standards, carriers and handset makers pick and you can probably avoid most of the mistakes in writ-
choose what to implement and omit. Recognize that ing a Java write-once-test-everywhere mobile app for
even though standards contribute to interoperability, it the phone.
might give you a false sense of portability and interop-
erability. • Adhere to standards. Despite the state of non-
standardization today, the desire is to simplify, stan-
• Not all mobile ecosystems are the same. In the dardize and have flexibility. Building an application
US, carriers have more control over the options a con- to any standard is better than defining a proprietary
sumer has for handsets, applications and services. In one. This is especially critical for applications designed
Asia and Europe where it’s more common for handset for carriers or handset makers. Some companies have
makers to sell directly to the consumers, both the car- tried to define standards in areas where standards are
riers and handset makers have relationships with the weak or non-existent. However, it is a risky and expen-
consumers. It’s important to know who your customer sive endeavor that might have more marketing than
is and how the chain-of-influence is ordered. technical value.
• Strict paranoid requirements are part and par- • Position your product like Lego. If your prod-
cel of the mobile world. Carriers spend a lot of money uct is targeted at carriers or handset makers, it’s almost
and effort to build and improve their mobile networks. impossible to sell an end-to-end one-size-fits-all solu-
This makes them rightfully paranoid about introduc- tion. It’s more likely that the customer will pick and
ing third-party systems into their backend systems choose functions they desire and require that those
and/or their phones. functions integrate nicely with their existing systems.
So, it is always better to architect your product to be
• The phone is sensitive to more things than the built out of loosely coupled components that can be
PC. Besides the value-add of an application, carriers easily and independently integrated with other sys-
and handset makers also care a lot about how an ap- tems.
plication uses the phone’s limited power, memory and
network I/O, and how it affects other functions on the • Open source your consumer app. This is an
phone. unconventional strategy that can have a lot of benefits
if done right. Let loose your source code and let the
With that in mind, here are some points you should community port it to their favorite platform. Offer to
consider in devising a strategy: certify the finished port for distribution with the mo-
bile network. There are obvious risks here. However,
• Question the value of a multi-platform app. having a community develop the product with you
You have to evaluate whether being on multiple plat- gives you access to user feedback and grassroots mar-
forms is a feature valued by your customer enough keting opportunities around our product.
for you to go through the effort of porting and test-
ing it across many different phones. If not, having this • Open up your consumer app. This is differ-
requirement might drain your resources better spent ent than open sourcing your product. This is exposing
working on features that differentiate your product. parts of your product for customization and improve-
It might be enough to choose the most popular plat- ments. One area that is suitable for such customization
form and rev your product a few cycles to get it right is the application UI. The mobile UI has always been a
before you port it to other less popular platforms. For challenge due to phones having varying form factors,
Techdirt Insight Community — Mobile Application Development Strategies, March 2007 5
screen resolutions, number pad and keyboard layouts. novative companies providing platforms that can be
Since there is no practical way to optimize the app’s UI disruptive to existing ones. These companies will pay
for each and every combination, the result is a less op- more attention to early adopters like yourself, and you
timal, lowest-common-denominator UI. Without hav- benefit from any attention they get in the marketplace,
ing to expose source code, you can open up that part just by the virtue of being one of the few early adopt-
of your app to customization and let the real users of ers. This way, your product doesn’t get lost among the
each phone model hack the best UI for it. Additionally, many choices a consumer has on a platform that at-
the company can potentially create a mini marketplace tracts many vendors and developers.
where people can sell/buy customized UIs for your
app, much like what some GPS vendors are doing by • Let business relationships drive the sequence.
exposing their voice UI, so 3rd parties can provide dif- In the mobile world, sometimes it is better to evaluate
ferent (celebrity) voices for audio directions. the carriers/platforms/vendors based on the kind of
relationship you can develop with them and go with
If you have to attack one platform at a time, here are the one that can provide the greatest opportunity for
some things to consider: support and distribution. In this case, it is impossible
to pin down any particular carrier/platform/vendor.
• Consider up-and-coming platforms. Besides If you use this approach, it can be educational to learn
going with the obvious choice of the most popular and how Danger got stuck exclusively on T-Mobile, where-
widely marketed platform, you might look into in- as Blackberry is available on all major carriers.
Techdirt Insight Community — Mobile Application Development Strategies, March 2007 6
response 2 Blogger: hersh
First a little background and a rambling analysis of the developers -- we are probably the first shipping prod-
options available on mobile: uct to try to use it.
My experience with mobile software has been limited So the correct strategy to pursue for an application
to consumer applications, and I’ve only shipped prod- launch is not independent of your application’s fea-
ucts for Symbian and BREW. So although I hope my tures. Do your features require only commonly used
insights about Java are accurate, they are less a result capabilities, or will you be trailblazers?
of hands on experience and are based more on discus-
sions I’ve had with other people in the industry. If you don’t need tight phone integration then there
The first thing to consider when planning for an appli- is no reason to not use Java for your application. It
cation launch is the feature set of your product. Are the has, by far, the largest addressable consumer market.
features you intend to support easily implementable If you DO have cutting-edge features and tight phone
on the lowest common denominator platform, or do integration then you might want to focus on a more
they require handset by handset tweaks? “full-featured” platform like Symbian/S60 or Win-
dows Mobile, as they will typically have better (i.e.
Simple features which migrate easily include things standardized) access to handset features. But they are
like text display, basic input, simple sounds, 2D im- a MUCH smaller market, albeit a market that arguably
age display etc. Things that don’t often have a stan- is more affluent and perhaps buys more content/ap-
dardized implementation across handsets are features plications (I have no data to substantiate that claim).
like 3D graphics, access to the camera hardware, mp3 BREW is something in-between; a fairly large market,
playback, integration with phone contacts database, with potentially more handset features exposed to the
screensaver functionality etc. developer, but also more complicated development/
To take just one example which I am intimately familiar porting.
with, 3D Graphics: there are several “standards” avail-
able for mobile 3D -- OpenGL ES and the JSR 184 Java The next thing to think about is how you are going to
specification, for example -- however the performance market and sell your application. There are on-deck
you get on a particular handset implementations vary applications and off-portal ones. If you are going to get
widely, and not just because of the variation in the un- on a carrier deck, then you either need a great sales
derlying handset hardware. In addition, many OEMs person, who actually gets her calls to the carriers re-
pay scant attention to supporting such “high-end” turned, or you need to partner with a mobile publisher
APIs, which allow applications access to more of the like Glu, EA, Hands On etc. etc. These publishers will
handset’s functionalities, and you often have to resort typically take 50% of your revenue in exchange for the
to third-party libraries to get support on a particular service of placing you with the carrier. They will do
handset. little else. The 50% split is simply because they get you
in the door – and by the way, this is 50% AFTER the
If your application intends to integrate with phone carrier has taken their slice from on top. On the posi-
functionality in any way at all, then your porting be- tive side, they may bring you some powerful brands
comes several orders more complicated. For example, or some marketing dollars to help push your applica-
the product we are shipping right now is a BREW ap- tion.
plication which needs to launch when the handset is
flipped open. Seems like a simple thing to do, especially Though this sounds far from optimal, it’s still better
since you would expect BREW to have a standard way than the dogpile which is the off-portal world. That is a
to receive a “flip” event and perhaps handle it? Well, black pit of literally 1,000 nameless applications -- you
that is not the case. The reality is that since Verizon lay- need to have some smart marketing to drive customers
ers their own custom solution on top of Qualcomm’s to your product in this mess. It’s a risky proposition.
basic BREW, and since OEMs are not held to strict qual- My opinion is that it’s better to go with a publishing
ity guidelines when implementing the BREW specifi- partner and to try to get on a carrier deck.
cation, most (in fact, all but two) handsets in Verizon’s
selection do not issue the “flip” event. The reason such As for choosing a carrier to launch on: ideally you
an egregious error is allowed in shipping handsets is would be launching on all carriers. And if you have
because it is not a feature which is commonly used by a good sales team, and a Java application, there is re-
Techdirt Insight Community — Mobile Application Development Strategies, March 2007 7
ally no reason why you cannot at least target the major and either i) partner with a publisher or ii) sell direct
US carriers with your initial launch. But, again, this as- to the carriers, assuming you have a good sales team.
sumes your application is of the lowest common de- Avoid off-portal unless you have a powerful brand-
nominator type that is amenable to deployment via partner or tons of money to spend on marketing. You
Java. will take the application to every carrier in the US you
can get a meeting with--everyone seems to have an in-
If you launch with a BREW application then obviously teresting addressable Java market. When you decide
your launch is much more constrained. The only major to go international the application will probably only
BREW carrier in the US is Verizon (Alltel, US Cellular need localization.
and Cricket are much smaller). The certification pro- • If the application has “high-end” feature re-
cess for BREW (True BREW Testing) is a colossal time quirements like 3D acceleration, voice processing,
sink and not insignificant expense. However, once you camera access etc. then your engineers may have
get through the testing you find yourself (assuming an easier time developing for Windows Mobile or
your bizdev team was good) on the much more rari- Symbian. However, this is only going to be interest-
fied deck of Verizon. Here you face much less competi- ing, given the smaller addressable market, if you can
tion (probably because TBT and getting on the deck are sell for a higher price point, so your application better
such a pain), and if you can get into the “Featured” list be compelling enough to justify the price. You may as
on the deck, then living can be quite good. But I cannot well shop it in Europe at the same time -- remember to
stress the importance of a good sales team if this plan is localize to Spanish, French, German, and Italian. With
to succeed. This is DEFINITELY not the plan to pursue the international angle you might be able to get some
if you are a small team of brilliant engineers, with one interest from a publisher. If you are going to try and
webmaster/sales guy. sell direct then you need a significant sales team -- or
a product that is so unique and compelling that it sells
I would not suggest a Symbian or Windows Mobile itself.
launch for a mass-market consumer application, un- • If you are going for a mass-market product, but
less there is no other option, since those platform mar- Java just doesn’t give you the capabilities you need,
kets are too fragmented and small, in the US, to allow then the next largest “uniform” market is BREW. You
you to get a substantial addressable base in a reason- need to get a meeting with Verizon, so hire a good sales
able number of development/biz-dev steps. You can person or get a publisher. Verizon is the biggest BREW
hit them in your second-wave of releases -- perhaps at market in the US. BREW is going to give you more fea-
the same time as you enter the EU market (Symbian tures than Java, but less than Symbian/Windows Mo-
has a healthy addressable market there). bile -- you are going to spend about $30,000 to certify
your application for the minimum required number of
So a strategy to summarize my thoughts: handsets for Verizon. When you decide to go interna-
tional you will end up porting to Symbian or Windows
• If the application is simple and does not re- Mobile -- BREW presence outside the US is not very
quire any special hardware access (like cameras or big, and in the EU it’s negligible.
3D acceleration), then you should create a Java app
Techdirt Insight Community — Mobile Application Development Strategies, March 2007 8
response 3 Blogger: Derek
Well, your first paragraph shows that you have run one of them, it becomes 20x easier to sell into the others
into the biggest problem with mobile development, with the reference case.
and understand it well. The second biggest problem
is the roadblock represented by the carriers and their • BTW, I’m not saying to avoid smaller carriers
walled gardens. They are a hurdle that normally needs like Alltel, USCC, Helio, Amp’d, or Virgin. Perhaps
to be jumped to get to paying customers. your app/content has a particular fit with them, which
might make them a principal target. Some times these
Here’s some practical advice: carriers are more agile, and fast to adopt new ideas.
But more often, they fall into the “telephone and email”
• The off-portal market is just starting to take sales strategy. Most content/app firms try to sell into
form in the US, and more so abroad. This market al- Cingular and Verizon, simply because of scale. Good
lows you to work around the carrier as a roadblock. argument, but that scale also makes them slower and
Your own website can sell the app, or you can work more arrogant. However, if your content/app requires
through big portals and aggregators like Handango. changes on the handheld software (or, God forbid,
The major downside here is that without marketing, hardware), the small carriers are much less likely to
who is going to ever find your app? If you’re ESPN, be able to work with you. That’s because, if a carrier
this might work, but if you’re an unknown, you will has fewer than 10M subscribers, it is very unlikely that
either have big marketing costs, or low adoption. they can get a hardware customization out of a Sam-
sung or Nokia. By the way, if your content/app does
• RE: the bullet above. Carriers love to see market require specific hardware changes on the phone, that’s
traction as proof of concept. If you actually sold some about as long a shot as there is.
units off-portal, it proves the app, the concept, the de-
mand, the functionality. Thus, and off portal channel • What’s a good strategy? Start with a LCD
can be used as leverage in biz dev with carriers. (Lowest Common Denominator) app if you can. Take
PayPal as an example. Their first app is an SMS P2P
• No amount of marketing can equal being vis- payment utility with IVR. It’s basically ugly, but it’s
ible on the carrier’s deck (on-phone catalog). That’s compatible with almost every phone out there. I would
why content/app providers suck it up to the Goliaths expect them to follow-up with a WAP interface, which
and hustle to get on deck. But don’t expect that to be is also LCD and compatible with a vast percentage of
enough. The carrier will probably do nothing to pro- the live handsets in the field. Other benefits include:
mote your app. And if my discussions with content little testing, no NSTL BREW testing requirements or
companies are any indication, most developers are fees (notoriously high). Of course, SMS and WAP only
angry at the way the carriers under-marketed, miscat- work for the simplest information-type of apps. A First
egorized, or buried their app. YOU will need to do all Person Shooter (FPS) doesn’t quite fit the LCD mold...
the marketing. The more you know this, and develop a So avoid FPS, and apps that rely on vector graphics, 3D,
plan, the more the carrier will have faith in your apps etc. If that’s what your app is, they you’re stuck with
ability to earn them money. the n X n X n X n complexity matrix you described,
then your game better ROCK and it’s time to go find
• Choose the carriers you target carefully. It’s a some more venture capital!
real resource drain to try to hit the big four, and the big
two in Canada all at the same time. I find it best to keep • By the way, with a LCD app, expect the carri-
an email or phone sales strategy going with all of them, ers to not “get it”. They would rather launch a lousy
but really only do a big push with focus, demo apps, 3D FPS, with vector graphics, customized avatars, and
and travel for one or two. If the situation changes, and stereo sound than a useful business application that is
doors close or open, adjust the targets, but trying to ugly (or even not ugly -- simply put, they prefer the
sell all the carriers at the same time is too costly - they flash). Trust me that the people who are screening apps
each assume you will be compatible with 20+ of their at the carriers are terribly unqualified to do so. That’s
phones during your sales cycle, so if you attack all, you not necessarily a condemnation of them, since the job
have the problem you outlined in your question. The of making decisions for consumers is over any one’s
main reason that you do not have to sell all carriers si- ability. So that said, let me therefore directly condemn
multaneously is the lemming factor: Once you sell into many of the people making the screening decisions as
Techdirt Insight Community — Mobile Application Development Strategies, March 2007 9
clueless. As an example, I built an educational gam- out for you and you will face far fewer decisions and
ing app with Leapfrog (by far the market’s leading surprises. As your experience develops, J2ME is a rea-
maker of educational toys), and the Leapfrog product sonable second platform. Depending on the nature
manager had to endure multiple meetings where an of the app, Flash Lite is becoming more widely used
(unnamed) US telco peon arrogantly told her how to for graphical apps, but handset support for it remains
best build an educational game. The gatekeepers are thin.
carriers are basically 20-somethings with enough balls
that they would give Ghandi advice on how to form a • When faced with n X n X n matrices, consider
peaceful resistance movement. outsourcing testing. Since the landscape of target hand-
sets is constantly changing, it is very costly to create
• Enterprise apps, though less sexy, are actually your own lab. Outsourcing this step is also expensive,
an easier target, since you don’t have to worry about the but less so - there’s no way around the fact that the
carrier so much, but you can sell into the IT dept. These matrix makes testing and compatibility cost money.
guys are looking for practicality and ROI, not pop and Consider TestQuest or MobileComplete as examples
fizzle. This works better with the LCD approach. Also, of mobile app testing houses.
it may be possible to work around the n X n device
complexity issue by building a targeted enterprise app, • Outsourcing and Core Code: Many develop-
and only developing for...say...the Blackberry OS. The ment houses create a core set of code which they re-use
challenge on this side of the business is that to sell into with all their apps. The advantages are faster devel-
enterprises requires a large sales force, which is prob- opment, lower costs, and easier testing. You can build
ably impractical for you, so you’re looking at partner- your core platform yourself, license one, or outsource
ships in the sales channel... Ingram Micro, telcos, SIs, development to a firm that already has one. I know a
or such. bunch of these firms big and small, but you probably
know the biggest ones, like ThumbPlay.
• The platform decision is shifting, but as a short
answer, perhaps BREW is the easiest thing to say (this • If you have a great idea for a mobile app, you
is US-specific advice). Don’t forget that if you can do could avoid all the risk and hassle by licensing your
SMS or WAP, that may be better because of cost and idea to one of these existing mobile development hous-
reach. For a full environment, BREW is an easy start- es. But be careful you don’t get your idea stolen!
ing point for developers because everything is mapped
Techdirt Insight Community — Mobile Application Development Strategies, March 2007 10
response 4 Blogger: jimh
Here is my strategy for developing a mobile applica- ket. Reputation for being difficult to develop on is re-
tion. Wow, that sounds simple, no? In my view there ducing with newer development tools, but don’t try
is no simple strategy for developing a mobile applica- this with a rookie development team. The new OpenC
tion, much as developing any other application there libraries will make porting existing C++/C applica-
is no silver bullet. tions far quicker.
The basics of mobile development are exactly the same Palm - U.S. market only, and dying fast.
as any software development process, you need a con-
cept, the means to convert this idea into functional soft- Windows Mobile - Has a good chunk of the U.S, mar-
ware, and a marketplace desperate for your product. ket, but again a bit-part player elsewhere.
The best way I’ve found to get from concept to reality
is by producing some realistic use case scenarios and i-mode - No significant presence outside Japan.
a good set of requirement documents, if your applica-
tion is being developed by a third party, getting the Flash Lite - Now appearing on S60 handsets, so poten-
details and right at this stage can reduce the confusion tially a big market, but is it too restricted for your ap-
and problems during development. plication?
As for mobile development there are unique require- Linux - Fragmented, no overall target yet.
ments there, primarily around the choices of target
market and target devices. Consider also the interna- A good graphical breakdown of the current market
tionalisation aspects of your development, can your can be found here - http://mobilephonedevelopment.
application work anywhere around the world? Are com/archives/322
you going to restrict it to an English-speaking audi-
ence? Are there cultural issues that will prevent your Other factors include data costs: has your target geo-
application from being popular in certain markets, for graphical market got flat-rate data plans? If not, how
instance American date formats in Europe, gaming are you going to attract people who are worried about
software in the U.S. etc. high data costs?
When you come to choose
your target device, here are a few rough guidelines of How are you going to get your application to market?
the current market breakdown: Are you aiming to get it onto an operator’s deck? Or
sell via sites like Handango?
Java - J2ME - On countless millions of handsets global-
ly, a first glance a good choice, but remember the write- Are you really thinking mobile-only? If you’re think-
once debug-everywhere and consider restricting your ing hybrid (web/mobile), are you going to restrict ei-
development to a few target handset models. ther approach?
BREW - Great in certain U.S. markets, virtually un- Lots of questions, and your development will throw
known elsewhere. up more, but if you can resolve most of mine in the de-
sign stage, you will have a good basis for the software
Symbian S60 - The biggest selling smartphone OS by development.
far globally, but has a minority share of the U.S. mar-
Techdirt Insight Community — Mobile Application Development Strategies, March 2007 11
response 5 Blogger: mgrosx
The difficulty in developing applications for the mobile of the US revenue for downloadable applications. Most
world is the lack of uniformity of platform. Only the carriers blocked or made difficult any downloads that
least common denominator of technology is available were not purchased on their content decks, thus ensur-
to the mass market: voice and text messaging. How- ing that applications were sanctioned by the carriers
ever, as capability of handsets increases and carriers/ and integrated into their billing systems.
operators developer more attractive pricing policies,
mobile applications are also reaching the mainstream. In the last two years, this market has grown substan-
Within the last several years, a viable market in ‘down- tially driven by a couple of different factors. ‘On deck’
loadable applications’ has developed. ‘Downloadable applications have seen their greatest success when car-
applications’ are generally defined as software written riers put a major marketing effort behind the effort,
in J2ME or BREW. These applications are either pre- both in-store and through general marketing, such
loaded or downloaded to the handset. as was the case with Verizon’s VZNavigator. At the
same time, ‘over the top’ efforts, perhaps best exem-
To take a snapshot of the US market, software on the plified through Google’s GMail and Google Maps ap-
handset is a recent innovation. As recently as 2005, a plications, have seen great success on carriers such as
single application, MapQuest Mobile, account for 20% Sprint, Cingular, and T-Mobile.
Techdirt Insight Community — Mobile Application Development Strategies, March 2007 12
response 6 Blogger: alex
This is definitely a tough question, a few points first : such as j2mepolish.org or Geniem and those often can
lead to good results... but if you run into any problems
If you want to address 100% of user-base, use IVR or you’re dead.
SMS. If you want to use anything else, be prepared to
lose a lot of the available user base! Fourth choice : Use Flash Lite, or Flash-like players
such as Streamezzo’s or Bluestreak’s. It might be the
The second choice would be WAP or xHTML mobile fastest way to make your mobile application and con-
browsing. Never underestimate this solution as it can nect to online services.
really bring some efficient service and information into
your mobile. Of course it’s not that sexy, but it is ef- Fifth Choice : do it by hand, platform-by-platform us-
ficient! ing native code... this one is really time- and cash-con-
suming but gives the best results and lets you really
Third choice : Java. It’s really not a write once run ev- optimize the user experience on each device. Don’t for-
erywhere solution ... Firstly, installing the application get that when you have good specifications you can
on the mobile is a pain for the user.. you should al- outsource that!
ways provide a SMS OTA provisioning system. Sec-
ondly making a good Java application is an art. There Start with Nokia Series 40, then Symbian/S60, then
are some tools available to try and simplify the UI de- Motorola (Java), Sony Ericsson (Java), HTC (Windows
sign (as regular Java widgets are really bad looking), Mobile) and you have most of it...
Techdirt Insight Community — Mobile Application Development Strategies, March 2007 13
response 7 Blogger: mikerowehl
The easiest way to hit the broadest coverage with Normally that means minimizing the information and
maximum value is normally to concentrate on the user actions available. If the desktop version of an applica-
experience end first to figure out what you want to tion provides a dozen pieces of info on each page and
develop. Frequently companies try to map a desktop the menus provide two dozen actions, the mobile ver-
applications to mobile platforms and treat the process sion should provide just two or three bits of info and
as a porting problem. But mobile offers one of those maybe a half dozen actions. Developing an application
80/20 kind of setups, where if you think about what for a mobile user base isn’t about offering the complete
the user of your system is really looking to do, you can set of what could be done in every situation. The sim-
frequently provide them a simple effective and efficient ple mobile applications are normally the most effective
way to do so without getting bogged down in details. ones.
Techdirt Insight Community — Mobile Application Development Strategies, March 2007 14
response 8 Blogger: daniel.taylor
Any vendor interested in developing a mobile applica- The consumer market can include traditional “consum-
tion should look long and hard at the consumer mar- ers” as well as workers who have provisioned their
ket. The reason is that the enterprise is a far greater own mobile devices. In western Europe, this second
challenge. category is much larger than it is in North America.
The enterprise is a longer-term investment with great- The next step for the consumer market is to address the
er risk and numerically fewer chances of success. Inte- Total Available Market (TAM) discussion. What plat-
gration and device management are major issues that forms will lead to the largest market opportunity for
can quickly become limiting factors for an application a given geography? I’m a big fan of Java applications
developer. Also, it takes a far larger organization to that are an easy download and can be supported on
support the enterprise market than it does consumers. a broad number of mobile devices (smartphones and
Indirect channels become critical, and an application traditional mobile handsets).
developer can find itself heavily invested in the success
of a program from a single wireless operator. Few ap- Going into the smartphone/PDA category for individ-
plications developers can withstand this level of risk. ual consumers reduces the TAM but does offer some
Keep in mind that Research In Motion took a “gamble” advantages for applications developers -- namely a
when the company invested in 100% indirect, carrier keyboard and a larger screen. I’d consider Windows
distribution for BlackBerry. RIM is the exception that Mobile and Symbian as key platforms.
proves the rule.
Techdirt Insight Community — Mobile Application Development Strategies, March 2007 15
Is your company getting the information it needs to succeed?
Reach out and engage experts by tapping into a valuable new information source
Techdirt Insight Community
A fast, cost-effective, actionable
alternative to traditional research
Quickly get feedback on Obtain a real understanding Create instant focus groups
products & services of what’s happening in your Gain valuable, informed,
Eyeing a new market? Or market third-party perspective from
maybe just wondering how the Traditional analysts will tell independent experts who know
market perceives a new of- you what you want to hear. your products, your market and
fering? Get fast and accurate They need your business. Our understand your business and
feedback. experts will tell you what you customers.
need to hear. They know your
Test Ideas Influence the influencers
Use our experts as a sounding Gain valuable insight into the Want to reach the new influ-
board as you map out your strat- actions of your customers and encers of your market place?
egy. We can help you determine competitors Use our service to reach out to
if you’re crazy like a fox or just How does the market really influencers and explain your
crazy. perceive that big deal your company’s value proposition.
main rival just announced? Is
it hype? Or do you need to be
Efficient and And more
Affordable These are just a few ways to leverage this powerful new tool. We’re sure you can come up with many others.
Learn more about our revolutionary new service at
www.techdirt.com or by calling 1-888-930-9272 x83
How We Have Helped Companies Like Yours
Market Opportunities Online and Social Media Sales
Assisted a major IT vendor Strategy Worked with the marketing
in assessing the market Teamed with a major team of a large materials
opportunity and in developing international food products supplier to give their sales
a strategy to sell computer company to develop a three team a deeper undertanding
hardware to online gaming to five year online and social of its customers in order to
companies. media plan. drvie more strategic sales.
White Paper New Product Development Strategy
Created a white paper for Dow Gave a web telephony Developed a five to seven
Jones focused on strategies company rapid feedback for year outlook for the growth
and best practices for helping a new online service it was of the digital entertainment
companies to create systems to preparing to release into the industry for a major
organize online data. market place. consulting firm.
A Few Of Our Customers
Praise for Techdirt
“Techdirt has a tremendous influence on the Wall Street Journal.”
--Kara Swisher, Executive Editor, Wall Street Journal
“Techdirt is a now a daily must read. The commentary is consistently smart.”
-- Chris Anderson, Editor, Wired Magazine