Which Phone To Develop For? 344
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."
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.
web based (Score:5, Insightful)
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.
Web Based (Score:3, Insightful)
Re:I'd go iPhone: (Score:5, Insightful)
"And apple takes only a 30"
Only?
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).
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.
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.
So your house stops working if your phone breaks? (Score:2, Insightful)
I'd go web-based or Java, since many phones support it.
Think of the problems if you develop for a specific platform and it becomes obsolete. I imagine your home will be around for many years, but I doubt any interation of Android or the iPhone will be. Unless you plan to change around your programming when you get a new phone.
Anything that has strong ties to legacy software or hardware will be supported for a longer period of time. Look at user-base, ease of installation and repair, and of course, the track-record of the company...Apple would be a bad choice, I can see them switching things up without notice and all of a sudden you can't dim your lights.
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).
Re:iPhone and OS X (Score:3, Insightful)
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.
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.
Re:I'd go iPhone: (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 contract anyway long before you start to worry about DMCA violations, so thats not going to matter. And since you never have to send your code to Apple or AT&T, you just submit the binaries, I can't imagine that you could possibly be talking about the iPhone.
So what phone are you refering to? Or do you just like spewing ignorant misinformation so you look like a anti-fanboy?
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.
I would choose (Score:1, Insightful)
I would chose a phone that I can develop for, without having to get on my hands and knees to beg permission to use their precious SDK. Self-respect, ya know.
Re:Openmoko Freerunner (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.
Stick with Java (Score:1, Insightful)
If you write it in J2ME, and stick to a relatively commonly used subset of J2ME, you'll be able to run it on any phone you might have that supports java. iPhone is a nice flavour of the month, but will you ALWAYS have an iPhone? If there's any chance of ever switching phones, suddenly all your objective C is useless. If you target J2ME, you'll be able to run it on any Blackberry or Nokia phone at least, and possibly Android as well (though admittedly I'm not too familiar with Android).
Write it once, run it anywhere. Makes sense, no?
No need for overkill (Score:4, Insightful)
Re:I'd go iPhone: (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 application the OP wants to write, and if it's not particularly complex or processor heavy, then J2ME might work great. But if it's something that actually does require substantial processing time, or require certain features or hardware on your phone, then you could run into a situation where there's a lot of phones that either run your software horribly or can't run it at all.
Non-tech-savvy consumers don't like trying to figure out which software they can run, or which software will run well. They often don't understand, or don't want to understand, feature sets or phone specs. But on the iPhone, they know that every single program they buy will run exactly the same on every iPhone. And that's a HUGE advantage.
"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.
Apple pulling the plug is a legitimate concern, and I agree that Apple's policy on how they handle rejected applications is pretty awful. But it depends on the type of application you're writing. Some types of apps so far have been completely safe, and only a few have been outright rejected.
As far as the OP is concerned, targeting the iPhone depends on whether or not the kind of customer base he wants to support is the kind that would use an iPhone or iPod Touch. The advantage is that the iPhone is rapidly becoming the most mainstream consumer level smartphone, and thanks to the huge amount of effort Apple put into it's user interface design, it's easily the most accessible, easy to use smartphone ever created. There's a lot of non-tech-savvy people who would never consider ever getting any other smartphone that would love to have an iPhone.
Re:Since you're buying more than one (Score:1, Insightful)
Develop Using an Open Platform (Score:1, Insightful)
Develop for the the Open Moko [openmoko.com] phone.
You will have control over the entire operation of the phone, and have the interface do exactly as you would like.
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.
Re:I'd go iPhone: (Score:4, Insightful)
Oh, wait...
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.
Re:iPhone and OS X (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.
Caching is critical - Maemo-Linux (Score:1, Insightful)
Nokia N800/N810 are Linux-based. They run a lite-gui called Maemo which is cross platform and GTK-compatible (i think).
Or just develop a web-app optimized for a few different screen sizes.
The issue that most folks miss is the "sometimes connected" nature that your app needs to deal with. If you are writing apps for businesses, much of the data should be cached local and uploads can wait until you have connectivity. Being out of service shouldn't stop the worker from moving on to the next task. Push the data later when you're back in coverage. The BlackBerry API knows about this stuff. I was responsible for deploying 20k blackberries with custom apps on them. The corp architects said to do a web interface so it could be reused inside the company too. They missed that about 10K of those users were in rural locations with spotty data coverage. The app was worthless for them. We had to implement a blackberry specific app that grabbed data for future jobs and cached data captured while on the job for later transmission.
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.
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.
Nokia, or 100% WAP (Score:2, Insightful)
Depends a bit on how compilicated the software will be. If it's very simple and a slow interface is not a problem, WAP + server-side PHP would be nice and the customers could choose any phone that supports WAP and GPRS (or whatever 3rd generation tech is used in the US) - which is practicaly any new phone in the market.
If you want to write the bulk software to run on the phone, I'd say Nokia's Symbian S60 line on Java, C/C++ or Python is a very good choice. It seems the C++ they use is a bit non-standard, but they also support Java ME which is much easier to learn. And Python.
Nokia has a pretty clean company portfolio, their SDK is based on Eclipse and all the relevant APIs are open, seem to be well-documented and full with developers manuals and code examples. forum.nokia.com [nokia.com] is their the developer's site. Personally I have never developed mobile software, but I know some people who do mobile game development, and at least their employers seem to prefer Nokia S60. S60 has a very extensive range of phones, including touch-screen phones, and there's also a free emulator available. Sounds good, but I have no first-hands experience what so ever.
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.
Re:I'd go iPhone: (Score:3, Insightful)
One's also legal, and one's illegal. (So is 'ripping' CDs you own.. I have never bought electronically distributed music [I have gotten some of the free tracks], but all of the music on my iPod is legal. I have considered buying the new songs on rereleased albums I already own the originals of, however... since the CD club I'm in doesn't seem to get most of the re-releases, or the Cranberries boxed set from a few years ago for example.)
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".
Re:I'd go iPhone: (Score:3, Insightful)
"And apple takes only a 30"
Only?
He covered that with the bit about the 'nice distribution system'. Apple's training their customers to pay for apps. The real question is: Despite the 30% cut, would a developer still make more money? The amount Apple makes is immaterial.
Re:I'd go iPhone: (Score:3, Insightful)
Only, including the cost of development tools, distribution, credit card processing, bandwidth, etc.
You write your app and upload it, and then Apple sends you a cheque. Sounds like a pretty damn good deal to me.
Re:YOu've missed the point (Score:1, Insightful)
There's nothing stopping a web service from passing in GPS coordinates.
Re:I'd go iPhone: (Score:3, Insightful)
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]
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.
Re:I'd go iPhone: (Score:5, Insightful)
Re:Because you're locked in (Score:3, Insightful)
Says the guy with the UID 30% bigger than mine.
Slashdot must be the only instance where men compares sizes, and smaller wins.