Slashdot Log In
Which Phone To Develop For?
Posted by
kdawson
on Fri Oct 24, 2008 04:16 PM
from the building-a-house-around-it dept.
from the building-a-house-around-it dept.
Rob MacKenzie writes "I have to decide on a mobile phone to develop for. We're building a house with some automation built in, and we want the mobile phone to be able to control certain aspects of it, and retrieve information on what's going on in the house. Our choices are the usual suspects: Apple's IPhone, RIM's Blackberry, Nokia's line (Symbian), any Android phone we can get in Canada, J2ME generic app, or a Web-based UI we would interact with in the phone's browser. What would you choose if you had to go with one? Which exact model? We will be buying a few to develop for, so price is a bit of an issue."
Related Stories
Submission: Choosing a phone to develop for by Anonymous Coward
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
I'd go iPhone: (Score:5, Insightful)
You can target the iPod touch as well as the iPhone, and can develop on the iPod touch as well as the iPhone ($220 development platforms with no per-month cost).
You have some very interesting features (accelerometer, GPS, camera) which make for some particularly interesting ideas
You have a large installed base thats still growing rapidly.
And apple takes only a 30% cut of revenue, in exchange for a nice distribution mechanism.
Re:I'd go iPhone: (Score:5, Insightful)
"And apple takes only a 30"
Only?
Parent
Re:I'd go iPhone: (Score:4, Insightful)
Considering that they are taking care of all the billing, credit card processing, accounting and running the distribution/download site, yeah. I'd call that "only".
Parent
Re:I'd go iPhone: (Score:5, Insightful)
Parent
Because you're locked in (Score:5, Insightful)
Except with many smartphones you aren't locked into a single point of sale. There are plenty of very good Windows Mobile applications that vendors sell directly to the consumer, for example.
Parent
Re:Because you're locked in (Score:5, Funny)
Plus, if you are already a .NET developer, the learning curve is almost nil. The number of phones is still large (and, if coded right, is just a recompile to run on things like netbooks and MIDs)......and you can make a desktop version, too.
Layne
Parent
Re:Because you're locked in (Score:5, Funny)
Eh, the mods must be crazy.
You must be new here.
Parent
Re:Because you're locked in (Score:5, Funny)
Incidentally, I've been noticing that "Iceweasel for Windows" link in your sig every now and then, what's really the point of using "completely free" software on an unfree OS? Not trying to start a flamewar or anything, but I don't really see the point of Iceweasel in the first place, and IceWeasel on Windows even less.
Parent
Re:Because you're locked in (Score:4, Insightful)
I do not have an iPhone, Windows Mobile Smart Phone, or Blackberry. I have a Nokia phone, and in the past i had a Motorola phone with Java.
The thing is, as a user, I dont know where to shop for Windows Mobile apps or Symbian Apps. The only app i ever downloaded was google maps on my Razor.
On the other hand, I do know where to shop for iPhone apps.
I'm sure there are thousands of places to buy or get mobile apps for the other platforms, but the thing is nobody is really promoting them to the consumers.
Apple is promoting its App Store directly to consumers, so if I was a developer trying to make money by selling to consumers, I would probably choose Apple.
But Microsoft, RIM and Symbian probably offer have better services and tools for developers (such as no stupid NDAs). If I wanted to make money by selling mobile enterprise apps, I might consider RIM or Microsoft instead, and target my advertising directly to potential customers.
Parent
Re:I'd go iPhone: (Score:4, Informative)
well, Android Market takes 30% as well. according to Google [blogspot.com], developers are required to pay a one time $25 application fee when they register, after which they're free to upload their applications without any need for validation or approval. so instead of having to go through Apple's block box approval process, quality control will be implemented through a collaborative filtering system (user ratings) similar to Mozilla's extensions library.
it's been stated that developers will receive 70% of the revenue from each purchase, so that's inline with Apple's 30% service fee. though apparently Google doesn't receive any of the money made from Android Market:
so again it looks like the cellphone carriers are trying to get their grubby little fingers on other people's money solely on the basis that they control the proprietary cellular networks the public depends on. well, at least it's good that Google is encouraging innovation and opening the platform to independent developers.
with the collective weight of the Open Handset Alliance [wikipedia.org] (which is composed of pretty much all of the major players in the mobile phone/smart devices industry) behind the Android platform, it has a good chance over overtaking Windows Mobile and dominating the mobile devices market. i mean, Android has pretty much vertical as well as horizontal integration. they've got all the major mobile carriers, software developers, handset manufacturers, semiconductor manufacturers, and handset manufacturers. the only big names companies that aren't behind Android are Apple, Microsoft, and Verizon. personally, i don't think they stand much of a chance against the OHA.
Apple gets their iPhone processor/chipset from Samsung and Marvell, both of who are now member of the OHA. and HTC, a major Taiwanese ODM that develops many popular Windows Mobile-based carrier-rebranded handsets has also joined the OHA. we know that their recently released T-Mobile G1/HTC Dream's Qualcomm MSM7201A processors (shared by the Palm Trio Pro) supports Android, so it's likely that other Qualcomm MSM line processors will also run Android. and it's reported that the HTC Vogue/Touch (Vodafone VDA Touch, Okta Touch, O2 XDA Nova, T-Mobile MDA Touch) can also run Android on is TI OMAP 850 processor. so chances are, other handsets based on the OMAP line will also support Android.
in fact, _all_ of HTC's smartphones [wikipedia.org], which represent a major segement of Windows Mobile handsets, use CPUs designed by other OHA members, including Texas Instruments, Intel, Samsung, Marvell, and Qualcomm. and if the one of HTC's Windows Mobile-based devices already runs Android, then the rest may will likely follow.
and a look at other Windows Mobile Smartphones [mobile-sg.com] shows that they all pretty much run on the same TI, Intel, Marvell, Qualcomm CPUs. so it seems these OHA members produce the vast majority (if not all) the CPUs used in mobile devices--or at least those currently running Windows Mobile. under these circumstances, i would not be surprised at all if Android starts supporting replacing Windows Mobile as the dominant mobile operating system.
Parent
Re:I'd go iPhone: (Score:5, Insightful)
You're practically self-parodying here...
You can target the iPod touch as well as the iPhone, and can develop on the iPod touch as well as the iPhone ($220 development platforms with no per-month cost).
Excluding, of course, the per-month AT&T contract.
You have some very interesting features (accelerometer, GPS, camera) which make for some particularly interesting ideas
All of which exist on other phones.
You have a large installed base thats still growing rapidly.
vs, say, J2ME, which has a huge install base that shows no signs of collapsing.
And apple takes only a 30% cut of revenue, in exchange for a nice distribution mechanism.
"Only" 30%? And they can pull the plug on your app any time they want.
All you've managed to do so far is to show that it could work, not why it's better than anything else.
Parent
Re: (Score:3, Insightful)
Excluding, of course, the per-month AT&T contract.
That's why he said to develop on the iPod Touch. You don't need a contract with AT&T for that, and it can do everything the iPhone can (except it doesn't have a microphone).
All of which exist on other phones.
But it doesn't exist on *every* other phone. One of the huge advantages of targeting the iPhone is that you are guaranteed to have a specific feature set that you can rely on.
vs, say, J2ME, which has a huge install base that shows no signs of collapsing.
J2ME ain't that great to develop for, because you have no idea what sort of hardware you're targeting. Of course, it totally depends on what sort of applicat
Re:I'd go iPhone: (Score:4, Insightful)
Oh, wait...
Parent
Re:I'd go iPhone: (Score:5, Insightful)
You're practically self-parodying here...
You can target the iPod touch as well as the iPhone, and can develop on the iPod touch as well as the iPhone ($220 development platforms with no per-month cost).
Excluding, of course, the per-month AT&T contract.
You have some very interesting features (accelerometer, GPS, camera) which make for some particularly interesting ideas
All of which exist on other phones.
You have a large installed base thats still growing rapidly.
vs, say, J2ME, which has a huge install base that shows no signs of collapsing.
And apple takes only a 30% cut of revenue, in exchange for a nice distribution mechanism.
"Only" 30%? And they can pull the plug on your app any time they want.
All you've managed to do so far is to show that it could work, not why it's better than anything else.
Excluding, of course, the per-month AT&T contract.
Yep, last time I used my iPod Touch I had to pay AT&T. Learn to read, please. You have some good points about J2ME, but spouting off non-sense doesn't help.
Parent
Re:I'd go iPhone: (Score:5, Informative)
Are you implying that developing and testing on a iPod will make the software sellable for iPhone?
Actually, that's absolutely correct. If you aren't developing an app that has iPhone specific features (camera, GPS or phone), then yes, developing for the iPod touch & the iPhone are the same for all intents and purposes. Quit trolling and do some research.
Parent
Re:I'd go iPhone: (Score:5, Insightful)
That's an excellent argument against the J2ME platform, and I've developed applications for J2ME, Android, and iPhone. With iPod Touch and iPhone, at least you have a good idea of the baseline capabilities of the device you're developing for. With J2ME, the devices are so different--and the providers configure them so differently--that you develop and test on a handful of different phones, finally get it to work on all of them, send it to a friend with yet another phone, and...it doesn't work. So you figure out what's wrong on his phone, and then you send it to another friend...and...it doesn't work. It's horribly frustrating. At least with the iPhone, you know if it works on your 3G iPhone, and it works on your original iPhone, it'll work everywhere. Hopefully Android will turn out to be somewhat similar. We'll only really know when there are a number of different Android phones available from different companies and different providers.
Parent
Re:I'd go iPhone: (Score:4, Informative)
http://www.gizmodo.com.au/2008/09/how_apple_picks_which_apps_make_it_to_the_app_store-2.html [gizmodo.com.au]
That is, unless it's a flashlight too.
Parent
iPhone: low hanging fruit... (Score:5, Insightful)
>
You have a large installed base thats still growing rapidly.
A good fraction of said installed base has money to spend. All of them have a track record of being separated from their money with only moderate effort.
And separating other people from their money is the primary motivation for going into any business.
Parent
Re: (Score:3, Insightful)
And which phone would you be refering to? Its obviously legal to develop apps for the iPhone since there are hundreds of apps available. Technically, Jailbreaking isn't illegal either so that can't be what you are refering to. If you are refering to sim unlocking, then you've broken your contrac
web based (Score:5, Insightful)
Definitely Web-Based (Score:5, Interesting)
If you design your system with a web-based system, you can even go ahead and add other types of device into the mix while still properly supporting a phone. Something that works with the aging Nokia 770's web interface, or even the newer 810 would work just fine with an iPhone, or any flavor of Windows Mobile.
In my personal experience, the iPhone would be a great platform for something like this - though the cost of entry isn't so great. However, the iPod Touch would do just as well unless you really need to have cellular access to things from long distances. The Mobile Safari interface is nice and clean, and the "Sliding" paradigm used in a lot of interfaces for it seems to be quite user-friendly and not too tough to work with.
Windows Mobile might be good for development of a standard application, and Windows Mobile devices are a dime a dozen these days if you don't mind going back a few versions. Unfortunately, the underlying OS is.. Windows Mobile.
You'll live in the house for decades... (Score:5, Insightful)
...but how long will any mobile phone technology last? Will you find yourself having to re-do it all every 5 years as phone/carrier makers obsolete what you developed for?
Web based makes sense since you could possibly transition to some other technology, or, more likely, a mobile device's web access will only get better making it in-place upgradable for a long time.
Building your software to target a specific phone technology just seems terribly shortsighted for something like a house.
(IMHO, the real answer is "none" -- home automation is of limited value past a programmable thermostat and ultimately an albatross of shit that doesn't work and is expensive and time-consuming to fix. Its frightfully expensive to maintain ordinary systems like windows, gutters, and roofs, let alone a whole complex automation system).
Parent
Re:You'll live in the house for decades... (Score:5, Insightful)
Web based makes sense since you could possibly transition to some other technology, or, more likely, a mobile device's web access will only get better making it in-place upgradable for a long time.
I'd teir it. A web service tier that does all the actual work. A web based front end, lowest common denominator UI for any device including a laptop, it uses the web service to get things actually done.
Then you can just build a phone UI directly against the web service for any device you want a more 'slick mobile application' for than accessing it via the web.
Parent
YOu've missed the point (Score:5, Insightful)
Technology is becoming agnostic.
Build a 'phone' ready web page and stop worrying which device will connect to it.
Re:YOu've missed the point (Score:5, Insightful)
If you build a web app, it might not be able to take advantage of the phone's hardware, like the GPS. I originally built a web app but bit the bullet and wrote a native iPhone app for this very reason.
Parent
Web Based (Score:3, Insightful)
Windows Mobile? (Score:5, Informative)
Why not develop it for Windows Mobile? It doesn't have as many restrictions as an iPhone or blackberry, is well established, is widely available, and has a good sdk.
Though, I will say that the most flexibility would probably be from a web-based app. Then you wouldn't be limited to a phone. However, it wouldn't be too difficult to make something that could work both on Windows Mobile and desktop Windows.
Unless you want to learn a new API (Score:5, Interesting)
Personally, having developed for Windows Mobile and the iPhone, my inclination would be to instead create a web-based UI.
The reason is simple: first, the web is pretty universal. You can (in theory) use it from almost any device with a web browser.
Second, it's going to be a lot easier to quickly prototype the control software than a custom client/server architecture with a custom protocol, which you'd get with nearly any mobile device.
And third, if you switch to a new brand of phone, you're not completely hosed; the worst thing that will happen are a few web page tweaks.
J2ME or Web (Score:4, Insightful)
Seriously consider using either J2ME or Web-based content. You can never rely on any one thing, but standards like these should allow you to change target platforms more easily in the future when the company you've chosen to follow either busts or, more likely, drops one of the features you've relied upon and you have a large amount of rework ahead of you.
(My fantasies always revolved around the Palm, but that was the standard when those dreams began).
iPhone and OS X (Score:5, Insightful)
The cool thing about developing for the iPhone is that you are *essentially* also developing for OS X. So its almost a twofer.
Re: (Score:3, Insightful)
Re:iPhone and OS X (Score:5, Insightful)
Wrong.
The basic principles are the same (it's all Objective-C and Cocoa), but the GUI SDK for the iPhone is not the same as that of a normal OS X GUI application.
Parent
Re: (Score:3, Insightful)
Oh, please. You said it yourself: "The basic principles are the same"...
Of course it is not *exactly* the same in terms of the interface and some hardware specific calls, but the core code for the kernel is *essentially* the same.
I'm doing this too... (Score:5, Informative)
...and the "easiest" solution is to go the web route. You can determine, based on the browser identifier, what is connecting to your web server and adjust the CSS accordingly. In our app, for example, I use a CSS library from Google Code to make the app look like an iPhone app when I detect it's an iPhone. I use a different CSS file when it's anything Blackberry.
Your server, therefore, is what should be the controller. I'm assuming you want to connect somehow to things like the air conditioning, lights, etc. The web server can invoke a CGI program, as an example, which talks to whatever serial lines are necessary to control said equipment.
Even better, you don't need to buy the actual hardware; get XCode and you get an iPhone simulator. Likewise, RIM has a simulator for every freaking model of every phone they've ever released (as well as for the different carriers).
Total cost to you should be zip for development purposes.
WAP & TAP (Score:5, Interesting)
WAP (a cut-down version of HTML) works on all small-format web browsers, and should be your *high end* phone interface. But also, you should have a secondary interface, based on a voice modem, that is audio/keypress, and which would work with all phones hands down full stop.
None of the above, because it's stupid. (Score:5, Informative)
Consumer-grade crap is crap and it'll fail.
Get a real automation system and wire your house up properly. Hell, with what you're spending on your phone "solution", you could easily get some PLC controls and wire up your house so that it will last for the life of your house.
Here's some less-expensive stuff, but still of very good quality:
http://web4.automationdirect.com/adc/Home/Home [automationdirect.com]
Of course, I'm just an EE that works in automation and control. What do I know?
Since you're buying more than one (Score:3, Interesting)
Buy a G1. It has the best tools (Eclipse) and the cheapest development costs ($25, and that's only if you want to distribute in the Android Market).
Blackberry is free unless you want to access certain APIs that require signing, then it's a one-shot $100. Their development environment is somewhat primitive, but you can use Eclipse and command-line tools as well.
iPhone, of course, requires a yearly $99, and they can reject you or your applications. You'd better like Objective-C and Xcode.
Series 60 (Nokia) is a PITA to develop for, though with them moving over to Qt that will get better. But don't expect their phones to be upgradeable.
Windows Mobile is easy to develop for, but Visual Studio will cost you.
bash & ssh (Score:3, Interesting)
No need for overkill (Score:4, Insightful)
Go with what you know (Score:3, Interesting)
My advice is, developing for mobile phones is generally more fiddly than for most platforms. Eg if you're used to developing J2EE/J2SE, J2ME is going to be familiar but irritatingly different.
The low hanging fruit is definitely the iPhone. I tried to develop for it. I failed. Here are my personal pros and cons:
Pro:
Great API exposing all the unique functionality quite well.
Good quality documentation, when you can find it. (See below)
That functionality itself is great too.
Easy to develop free apps and getting them into the iTunes application store is actually pretty reasonable and easy.
Cons
Objective C. I really just don't like it. REALLY don't like it. As a Java developer, it has some niggles that set my teeth on edge.
The development environment. If you're used to Eclipse for instance, you might not like XCode. I didn't.
Documentation on slightly deeper subjects is not always easy to find. I was sometimes left scratching my head at strange behaviour that seemed undocumented, with no recourse to investigation other than Google. This is poor.
Buying an iPhone is not cheap, specially with the contract. Guess you could get away with an iPod Touch for most functionality.
YMMV. I decided to use someone else's apps, who was already developing something close to what I wanted to do anyway. Pity, but it just wasn't worth the pain to me.
PalmOS (Score:4, Funny)
It's the granddaddy of PDA OS and it's making a comeback.
I said it's making a comeback, dammit.
Grr.
do NOT choose a phone (Score:4, Insightful)
Don't design around a any phone that is on the market today. design around some standard interface. the you program whatever phone is popular this month to use that interface.
Which audience is more likely to buy a phone app? (Score:5, Funny)
Apple users are well-trained to pay premium for everything, from the iphone accessories to the software applications.
I'd go for the well-paying techno-lusting, in-love-with their device user base.
While the bberry is highly addictive, it's used almost exclusively for the simple tasks of email/calendar/phone.
May I interest you in developing a $10,000 application which will display a message saying "I am filthy rich and you are my bitch!" on said device?
Good luck!
Comments on Blackberry, Windows Mobile (Score:4, Informative)
I've developed for both Blackberry and Windows Mobile. You can develop for both platforms for free, and do not even have to sign applications. With Blackberry you do have to sign your application to use certain Java classes deemed "secure". It costs $100 for a license allowing unlimited signing. However, you can do full J2ME (plus some BB APIs) for free. Blackberry UI, processing speed and graphics capability is very, very poor. I have recently been experimenting to push Blackberry graphically, and have hit nothing but dead-ends (for example, the native display is 16 bit RGB-565, but all APIs to push raw image data are 32 bit ARGB 8888, so a very slow conversion is done by the system). However if you stick to API-supported rendering (basic font rendering, blitting with alpha channel, simple drawing primitives) then you can do quite a bit with good performance. Just don't expect to be able to do your own bitmap-level rendering in realtime (like rotozoom, bumpmapping, texture mapping, etc). All development must be done in Java.
Windows Mobile offers a ton of CPU power and RAM (I've ported both Quake I & II for example). Devices are available with 3D accelerated GPUs, touchscreens, VGA-resolution displays, CF, SD, Wifi and Bluetooth (all in a single device even). So as far as raw options in hardware capability and form-factor, Windows Mobile gives you the most choice. If your app will do some really heavy lifting graphically then Windows Mobile is the better choice. You can develop in the widest variety of languages for this platform - C, C++, C#, Java, ARM assembly, Pocket C, and Visual Basic (just to name some off the top of my head). With both iPhone and Blackberry you are restricted to a single language.
As far as iPhone goes, I've not delved there at all. Things I've heard that concern me are a non-standard programming language, restrictive distribution policy, and whether or not you can simply write and build an app and stick it on your own phone or not without having to sign it or otherwise register it with Apple.
Re: (Score:3, Interesting)
The devilish thing is that mobile phones today are as the personal computers were before the IBM PC and MS-DOS appeared on the market.
Not that it was the best product that took over then, and we are still waiting for the 'killer phone'.
Apple could have taken that path if they were more open but from the perspective of a developer they are a locked-up dead end.
The phones that I think are the ones that's easiest to develop for are the Windows Mobile phones (horrible thought), but I haven't seen the Android ye
Re: (Score:3, Insightful)
Thank you! I was reading retarded reply after reply, and was wondering why no one was mentioning the obvious.
The openmoko is clearly the best choice here, since you need to be able to have full control over your application if you want to do stuff like opening doors. Who knows what backdoors are hidden in the closed phones.
Re:Openmoko Freerunner (Score:4, Interesting)
I don't know, I'd prefer to develop for a phone that people are using.
Developing for the iPhone or J2ME means at least you have quite a large installed base for selling your software.
Parent
Re:Openmoko Freerunner seems like trash (Score:4, Informative)
You can get the phone in Canada RIGHT NOW [koolu.com], you don't have to hack it like an iPhone or beg someone in the USA to send you one like the G1, and it is completely open source so there is no stupid EULA's to get in the way.
You know, in some ways that phone is real appealing... Particularly the whole "hackable" aspect. In other ways it looks like complete garbage, at both the hardware and software levels... I have trouble these days getting past the lack of a keyboard. I mean, I was a Palm fan until they decided to stop meaningfully improving the OS, so I'm down with pen computing - but I've also been using a Treo 650 for a couple years now, and I use that built-in keyboard all the time. I hate the idea of being without that.
I would be all over the G1, personally - except I hate the idea of a mobile device that doesn't allow you to develop and install native code. I don't like the idea of a Linux system that can't run "bash", or run the same software I run on my Linux machine at home... And I don't like the whole idea of my phone having to waste cycles converting one instruction set to another. I've had enough of that on the Treo with PACE.
Of course I recognize the benefits of a virtual environment for sandboxing, and of an API that's really designed for phone use... But to me the point of running Linux on a device is to be able to do Linuxy things with it...
All this is almost enough to make me turn to Windows Mobile - it doesn't require everything to go through an emulation layer like Android does, its operating software is a lot more mature than OpenMoko, you can get decent hardware for it (sliding keyboards, etc.)... Basically, it's still more of a "portable computer" system adapted to work as a phone (like PalmOS on the Treo) rather than "high-functionality phone" system like Android...
Why they gotta make this so hard? Android looks great except the whole "Linux appeal" is negated by the fact that you apparently can't actually get at it...
Parent
Re: (Score:3, Interesting)
The BlackBerry-specific API exists because J2ME has traditionally been far too limited and incapable for what they want to do with the platform.
That being said, I just came from the BlackBerry Developer Conference and have an interesting tidbit to share...
Whenever they were implementing some new feature, whenever possible, they did it based on a JSR, and not their own home-grown API. Seriously, the presentations were littered with references to JSRs.
Re:You're missing one. (Score:5, Insightful)
Problem with Windows Mobile: the software market is dysfunctional: no central app store like Apple for at least another year, sites like Handango take 40-70% of your revenues, and WiMo market share is dying. Dropped from 24% in 2004 to 12% this year. Look at apps that are available: ugly, expensive, and lame-o. Consumers aren't attracted to that, and the installed base is falling apart. Microsoft sold 18 million in the last year, not even twice as many as the iPhone, except that the iPhone is one platform; all the WiMo devices are slightly different, with different features and capabilities, from non-touch tiny Smartphone screens to larger Palm-style Pocket PC form factors.
Look at RIM: Apple just passed them in sales this quarter. RIM sells replacement phones to a relatively slow growing base (19 million subscribers total, again less than double Apple's sales this year). Its installed base is also spread across a variety of different models.
Palm is dead.
Symbian is big but struggling. Difficult to develop for, has the same problems with marketing apps as WiMo. Nokia sells a lot of phones, but most don't run Symbian but only the feature phone Nokia OS. It's Symbian products are split between different hardware types, and the overall Symbian market is currently split between three platforms.
Flash Lite and Java struggle to run on hundreds of slightly different phones, which all have the same software marketing problems. Android is basically just a semi-consistent version of Java ME, the hardware will still be all over the place. Installed base is currently very small, and the G1 isn't going to help in that regard.
Apple's iPhone has a single installed base of over ten million units, and growing dramatically. It has a wildly profitable marketing system for software, good development tools that share a lot in common with Mac development, and a customer base that spends money. There is no real variation in hardware to deal with, nor problems between the software/hardware vendor.
So if you want to do mobile software to make a political statement, or because you like a certain technology, or just want to keep yourself busy, you have several options. If you want to make money, you write iPhone software and sell it to the ten million iPhone users and several million other iPod touch users.
Five More iPhone Myths [roughlydrafted.com]
Myth 6: iPhone Developers will Flock to Android [roughlydrafted.com]
Myth 7: iPhone Buyers will Flock to Android [roughlydrafted.com]
Myth 8: iPhone will lose out to Steve Ballmer's Windows Mobile 7 in 2010 [roughlydrafted.com]
Myth 9: iPhone Unable to Penetrate Europe Due to Symbian Dominance [roughlydrafted.com]
Myth 10: RIM's BlackBerry Will Contain iPhone Expansion [roughlydrafted.com]
Parent