Which mobile platform would be more rewarding to learn as a developer (iPhone vs Palm Pre vs. Android)?

Question

I am interested in getting my feet wet in PDA/mobile development. The only two drivers for me are the drive to learn cool (or at least, new) stuff, and may be to code some app that I felt I really needed but lacked.

As such, I would like to know what the comparative benefits/downsides would be for me as a developer in choosing one of the three platforms (iPhone vs Palm Pre vs. Android - I will have access to any of the 3 but not to Windows mobile). E.g.

• What exciting new technologies I can learn?

• How good the available development environments are?

• What existing frameworks/libraries are available or are under active development?

• How well documented the platform and APIs are?

• What neat features of the platform are accessible via the APIs vs. blocked off?

• Any other developer-centric considerations I missed?

I am pretty open to either the benefits of leveraging my existing skill-set to ease the learning curve, or the benefits of learning something entirely new and cool, so while I'm curious how the platforms' development relates to my current set (recently, Perl, SQL, web development, C++ and some Java, but I'm also quite comfortable with functional programming), so it will not be a deciding point.

NOTE: This is not a duplicate of this question, since I do not care at all about that question's data points (cost of the handheld, popularity of the platform). Also, just to be clear, my goal is not financial at all - I don't plan to make money off of such development nor directly use the skills in the area I might obtain in my career (e.g. I work on stuff that has zilch mobile exposure and will remain so). So concerns such as "installed user base" are pretty irrelevant. All I care about are tangible (learning) and intangible (sheer joy of it) benefits to me as a developer.

Also, please be positive and don't put down other platforms or otherwise use this as a holy platform war excuse. I have edit privileges and will mercilessly edit any un-backed-up-by-facts attacks on any platform that aren't downvoted.

Answer 1

As much as I hate to say it, I believe the iPhone would probably be the platform you're looking for.

It has exciting technologies - you can use Objective-C, MonoTouch, XnaTouch...it just depends on what you're willing and able to learn.

The development environments are solid - XCode or MonoDevelop...it's your call.

Well documented APIs

The broadest user base to distribute your application to.

...the only downside that you didn't mention is that you have to go through an approval process to get your app distributed. Depending on the purpose, this could be easy or it could be damn near impossible.

Answer 2

I only have hands-on expertise with Palm Pre of the platforms you've listed, so..

• webOS has great documentation available on Palm's developer site
• It's a growing platform which gets better with each release
• Technologies you get to work with are browser-based, such as JavaScript
• Palm's development tools are great. The emulator is very good, and deploying apps both to the emulator and the actual device is very streamlined.
• To debug your applications you can get logs from the device or attach the Webkit dev console

Other things that come to mind

• JavaScript as a language is quite interesting and you can do lots of cool stuff with it
• The technologies used to develop webOS apps are valuable otherwise as well: You can apply the same knowledge to build web applications for "normal" computers
• Only downside is that at this point there is not much of support for doing 3D graphics or such, but 2D is feasible, and quite likely the situation will improve in the future.
• There's a growing homebrew app community, and information on how to utilize the Linux OS hiding behind the sleek UI. See webos-internals wiki

Answer 3

I think this is a great flipside to the question of which platform is most financially motivating.

I think you've hit on the right three platforms to consider, and here's my take as a technologist about what I find appealing about each (caveat, I've only done serious programming for the iPhone and not done more than looked over API's or written very small test apps for the other two platforms):

Pre: This platform I think really explores the intersection of touch and multitasking. The very fact that apps are practically encouraged to run all the time, combined with the "card" metaphor make for a focus on small applications that are laser-focused. Some people complain this is back to the same web-development level the iPhone had but that's not the case, the Pre has a real API lurking under the Javascript that you can call into (which the iPhone has to some extent now as well).

Android: This platform is a lot about customization, in that you can extend the platform much more and so beyond writing apps you can also write interesting system extensions or changes.

iPhone: Here the focus is on touch, and applications with a really good user experience - and more applications in the traditional sense, in that they can be really fully featured. That's true on Android as well of course, though because of the variety of hardware I'm just not sure it's practical to deliver the same quality level you can on the iPhone. iPhone also has a more extensive set of frameworks than the other platforms, with especially cool and useful things like CoreData for data handling and CoreAnimation for very easy to use animation effects just about anywhere that can really enhance the usability of an application by giving visual reinforcement to function.

I think the way I'd partition out the direction to go would be, that if you really want to write applications that just happen to also be mobile apps or explore really unique UI approaches the iPhone is the way to go (the richer libraries around display and input making it easier to express non-standard input concepts). If you want to tinker more with adjusting the system Android might be best for you, and if you really wanted to write small things but get deeper into web technologies that could carry back into server side delivery (like advanced CSS) the Pre would be a good platform.

A hybrid approach can work as well, someone combining both financial and spiritual reward considerations might well primarily develop for the iPhone, but also spend some time tinkering with the Pre.

There is one last thing to consider, is that there are really two iPhones - the iPhone that they sell, and then the jailbroken iPhone that millions of people use. I was at a Pinch Media (they make an analytic package that gets embedding into various iPhone apps) presentation recently and they said they had tracked around 3M unique users from jailbroken devices. The jailbroken iPhone also includes lots of system customization abilities, and furthermore has an exciting extension mechanism that lets you fiddle with the behavior of individual apps by writing small plugin-like code for them.

Whatever path you choose, I hope you find enjoyment.

Answer 4

I've done development work on all three, and they each have their pluses and minuses.

Two minor downsides to iPhone development are that you have to have an Intel-based Mac for development, and you have to pay $99 to join the developer program if you want to run your programs on an actual phone or iPod. he other two platforms let you use Windows or Linux, and you don't have to pay anything just to play around.

Android never really captured my imagination as a platform - it's okay, and all, but doesn't have the same fun quotient as developing for the iPhone. The documentation was terrible, but I think it's getting better.

I just recently started working with WebOS on the Pre, and it's a lot of fun. The SDK and tools are a little rough (as you might expect for version 1.0), but it's fun working in JavaScript (a language I didn't previously have much experience in).

So, to answer your questions:

What exciting new technologies I can learn?

On the iPhone, Objective-C and the Cocoa framework. If you haven't developed on a Mac before, this'll be an interesting experience. There's a LOT of functionality there in the API, and the approach they take is very unlike a lot of other OOP frameworks, with a concentration on composition and delegation, rather than subclassing and containing.

Android is more-or-less just Java with a different UI library. I didn't get fully engaged with the SDK, so maybe there's something cool there that I missed.

The webOS platform is something very different. It's closely based on the JavaScript environment loved (and hated) by web developers, of course, but there are enough extensions to make it possible to write "real" applications. It seems pretty straightforward to do the usual device-specific stuff.

How good the available development environments are?

I happen to like Xcode, so I think iPhone wins here. In addition to the IDE, Apple also provides tools for profiling and performance tuning that are quite nice. With Android and webOS, you're likely to be using Eclipse with the appropriate plug-ins. Eclipse and I don't really get along, which was probably part of why I didn't get into Android as much.

What existing frameworks/libraries are available or are under active development?

Don't know about this for any of the platforms, really - what was provided by the base SDK was enough for the things I wanted. I think iPhone has a lot of third parties working on frameworks for various things. Most any JavaScript library works on webOS, so there are a lot of interesting libraries there, from JQuery, to Prototype, to whatever...

How well documented the platform and APIs are?

iPhone: 9/10 - some of the developer tools could use better documentation, but the API framework documentation is top-notch.

Android: 7/10 - lots of documentation. Hopefully, it's more up to date now than it was in the Spring.

webOS: 7/10 - some parts are documented better than others. Being able to look at the Javascript app and framework code helps in cases where the documentation is less clear.

What neat features of the platform are accessible via the APIs vs. blocked off?

Android is very open. The iPhone has some weird limitations, though they tend to get better with succeeding SDK versions. I think webOS is currently the most limited in some ways - the JavaScript API doesn't allow for low-latency sound or graphics, so most games are a non-starter. Presumably, more APIs will be available in future releases.

Any other developer-centric considerations I missed?

Can't think of anything.

Answer 5

I have experience of developing commercially for the last years for iPhone and Android. I have only written "hello world" for webOS, so I will not mention it here.

Documentation

My experience is that the iPhone is the shining crown jewel, it plays in a league of it's own. The documentation and tools are pristine. Everything in the public API:s are well documented, and the example projects from Apple covers pretty much everything. The Cocoa Touch framework is well thought out and consistent; learn how one class works and you can intuitively know how the next works as well.

Whereas Android at version 1.6 still feels like an alpha where the API:s still needs sorting out. The documentation have many gaping holes, most constants never describe what they do, just what they are. The API is inconsistent and has not even figured out if it should be Object Oriented or not. Dialogs are the best example, where you define integer ID's and use several callbacks in a C-like fashion to display the dialog, but on the other hand have a factory class that is OO to an almost over engineered degree to actually create an alert dialog.

Programming Language

Cocoa Touch plays well with the Objective-C language and it's dynamic nature. Evident in basic paradigms such as delegation, and target-actions. And making cool frameworks such as Core Data tick.

The Android API:s are build on Java 5, but for performance reasons many Java 5 features are not used at all. Most evident is the complete lack of enums, and instead using non-type safe int constants, sometimes but not always with prefixes to help you with type safety.

Designing User Interfaces

The iPhone SDK features the Interface Builder, a GUI tool with WYSIWYG editing of user interfaces. IB (Interface Builder) is a kind of different beast than most GUI editors; it do not generate code, or even "recipe" files in XML or some other format. IB instead works with live objects that are serialized, or archived on Obj-C parlor. That are then unarchived as live objects at run-time. Takes some getting use to, but works great when understood.

On Android you define UI in XML files, that care "inflated" in Android parlor at runtime. This is a great idea and works really nice. Mostly because I personally hate the auto generated code blocks marked as "do not edit" (that you 11 times out of 10 have to edit anyway, breaking the tools). Constants to UI elements int he XML files are auto generated for you. On the downside the documentation for writing said XML files is almost non-existent, and there really shold be a prober drag-n-drop tool, not plain XML.

Performance Profiling

On the iPhone SDK you have a nice tool called Instruments, it is build on top of SUN's DTrace tool. Use it to profile any running application on simulator or on device. No changes to source code, just start Instruments and click the Record-button, for real-time profiling of: memory, CPU, leaks, GPU, ets. Then find your spikes on the visual graphs and display actual stack-traces for the bottle necks, double click to show your source code inline with overlays for percentage of CPU spend on each source line for example.

On android you can add the statement Debug.startMethodTracing(String filename), in your source code. And then use the traceview tool to inspect the result, after pulling the file out of the emulator or device. It works, but is not quite as nice.

Persisting Data

On iPhone OS you have a very nice framework called Core Data, it is an ORM on top of SQLite databases. You have a visual graph tool for designing your entities with attributes and relations. As well as visually designing version upgrades. All SQL is hidden away. By default all entities are handled as instances of NSManagedObject and values are fetched like if from maps, if you like you can implement your own subclasses of NSManagedObject with extra logic, assign them in the visual tools and Core Data will instantiate your classes instead where approperiate.

Android also uses SQLite and have a really cool feature called Data Providers, where data can be shared between applications. Data is requested by URI and returned as traversable cursors. From client side this concept is very flexible, brilliant actually. On server side not quite as nice, as you will have to implement most of the mapping from URI down to SQL yourself. Often in two layers, from from an URI-mapper to actual requests, and then down to SQLiteDatabase queries, that are SQL but not quite.

Open GL

On the iPhone you have OpenGL ES 1.1, or 2.0 for iPhone 3GS and latest iPod Touch generation. Since Objective-C is a strict superset of C, you simply use the official OpenGL ES headers. A cool note is that all UI is hardware accelerated using OpenGL on iPhone. All UI elements are backed by instances of CGLayer that is an abstraction of a OpenGL polygon. This means that UI composition, translation, scaling and all other transformations are done on the GPU. On the downside no UI component can be more than 1024x1024 pixels, if you want more you must do tiling.

On Android you have OpenGL ES 1.1 with Java-bindings - JSR-239. It works as expected, ut requires use on byte, and int buffers for transferring actual data from the Java run-time to the native OpenGL ES implementation. The "normal" UI is software rendered, so if you want GPU acceleration then you must use OpenGL explicitly.

User Interaction

The iPhone is touch only - period, no hardware buttons that 3rd party applications can take advantage of. On the upside the touch API:s are all designed for multitouch. Currently the platform supports up to 5 simultaneous touch points, the API do not expose this platform limitation. The APIs also exposes support for rudimentary gestures such as swipes and shakes.

An android you have many more input methods; hardware buttons, full qwerty-keyboards, track-balls, and not the least touch. The touch API as on Android 1.6 is bound to 1 touch point, so multi-touch can not be realized without introducing new APIs. This is a major drawback for games, making it impossible to implement a play-scheme where you can shoot at the same time as walking on touch-based inputs, very important now that devices without physical buttons are coming to market.

Answer 6

Speaking only for myself (a developer who had gotten into management, and turned to iPhone development to refresh my skills), the iPhone was a dream platform for investigating new technologies.

The programming language (through normal channels) is Objective C, and other than the somewhat unusual syntax for sending a message to an object... it's just C syntax. In that way, it was a good springboard to C#, Java, or even back to C itself.

As far as refreshing design skills... I know some will disagree, but I think that Cocoa is a work of art. The library rivals Java in it's scope, it is exceptionally well documented, and the iPhone version (Cocoa Touch) strongly encourages a nice MVC approach to the UI.

With about a year of iPhone fiddling under my belt, I realized I liked coding more than managing and switched right into a Java coding position with little ramp up time at all (I was managing a .NET team).

So both personally (it was just FUN) and professionally (allowed me to get a new and better job) iPhone development was the right path for me.

I can certainly see how I could have accomplished similar goals with Android (since, as you say, the income from the development itself is not a factor), but it's frameworks were not as mature as Cocoa on the iPhone. WebOS was not available at the time I made my decision (although I doubt I would have gone that direction, due to WebOS's emphasis of client side technologies [javascript, css]).

Answer 7

You should consider which platform/s provide you with freedom to play around with it?

Answer to that will be answer to your question. For me its Android.

Answer 8

I'd echo others that are recommending iPhone, due to the multitude of good reasons mentioned above. I'd also add the Blackberry and it's usage of Java ME if your familiar with Java at all.