Why Smule won't be developing mobile apps for Android | Hacker News Reader

Why Smule won't be developing mobile apps for Android

edibleapple.com

16 pointsanderzole18 comments

Because they're very clearly an Apple-only bunch, being interviewed for an Apple news site?

I don't really get it. Are they claiming that "I am T-Pain" would be expensive to build on Android because they would have to test it against a bunch of different devices and UIs? As far as I can tell the app shouldn't require any fancy UI elements. You just need a microphone and a speaker right?

It doesn't 'require' fancy UI elements but that's what makes a decent app good or a good app great. Having lots of fragmented hardware to support (eg multiple resolutions) is a pain.

Multiple resolutions is not a problem, it is just pathetic excuse of Apple fanbois. Just wait, until Apple comes with iPhone using higher res, then of course it will be best thing since sliced bread and Apple will be first with such a novel concept.

Multiple resolutions is a problem compared to one resolution, you don't have to be an Apple 'fanboi' to realize that. Most artwork isn't vector and has to be recreated appropriately. Apple of course will upgrade the resolution (probably this summer) and it will create problems for iPhone developers as well. Another concern is no clear baseline of the Android hardware, considering it can run on anything from microwaves to tablets.

Also what if Motorola's microphone is sourced from a different supplier and has a different level of noise coming into it and it causes the app to not function, thousands of angry users and Smule's reputation is ruined. Predictability is a huge advantage.

Here's why:

1) they don't have the money to develop for both the iPhone and Android.

2) announcing they won't develop for Android will bring them some needed publicity as it did for that gaming company who did last time.

3) if they don't have the funds to develop for android and make money out of it, they may as well try to cash on the fact that they won't be developing for Android.

All and all, pretty pathetic PR.

Over 4 million apps at around $2-$3 a pop? I'd say they have more than enough money. They also raised $8 million in December http://moconews.net/article/419-smule-adds-8-million-second-...

I think you're trying to minimize the difficulty of the android platform:

1> Pure Compute Power between handsets varies widely. You can't do something that requires significant compute power without functioning poorly on the less powerful handsets.

2> Screen resolutions are all over the place (You have to test on 5-8 different resolutions). This is KILLER for someone doing a game or other fixed width layout. It's not like you see 15 different sizes of flash windows. MOST people can't afford to do multiple sizes.

3> Installed OS version is all over the place. While there is a supposed "upgrade to 2.1" happening later this spring for all handsets, I predict many handset owners won't do it, as it will require a data wipe.

4> The Tools Batman. Interface builder is leagues upon lightyears better than hand edited XML based java container layouts. You have easily 10x the layout and positioning work for Android, and you have to test this layout and positioning on all the different phones.

5> The installer: If your app has any amount of data in it, you have to write an installer and sell the installer, which then downloads your app. This is expensive.

So yes, you're technically right, they don't have the money or don't see it a worthwhile investment to try to target the crappy android development landscape.

Perhaps someone will make a unifying toolkit that does screen layouts well and is in Python or another one of the ASL toolkit, but with the current old school java development kit that is android, it's not going to be a winning target for many developers.

> The Tools Batman. Interface builder is leagues upon lightyears better than hand edited XML based java container layouts. You have easily 10x the layout and positioning work for Android, and you have to test this layout and positioning on all the different phones.

"Designing your interface on the iPhone is easy. It's fun. It's intuitive. On Android, it's fucking hell. It's like working with the evil offspring of GridBagLayout and XML. It's utterly horrid. But, Java has never done UI well and has never made it particularly fun so I can't say I was surprised by this, though it did exceed my expectations by being even worse than I thought humanly possible. The whole process is counter-intuitive and time-consuming, and that's just to make something that functions. It's even more time-consuming and painful to make a UI that doesn't look like ass."

Android SDK from an iPhone Developer's Perspective

http://iphonedevelopment.blogspot.com/2010/03/android-sdk-fr...

I've worked with both, and I can't really disagree.

Android interface work IS a pain. "Counter-intuitive and time-consuming" is a very good way to describe it. The fact that Eclipse is often painfully slow on my Macbook doesn't help. On the plus side, I was pleasantly surprised that the layout DOES scale well for different screen sizes - which is the whole point of jumping through all the hoops in the first place.

iPhone interface work isn't perfect, either - Interface Builder only gets you so far, and its strength is fixed layouts - once you throw in variable size elements, you have to do a lot by hand.

I'd rate Android's interface system as a 7 or 8 on my personal "annoyance" scale, and iPhone a 4 or 5. I enjoy Android more than iPhone overall, but the interface is definitely not its strength.

At the risk of telling you something you already know:

I was having trouble with Eclipse running painfully slow on my MBP until I discovered it was using the 1.5 JVM. Switched it to 1.6, and now it's bearable.

Re point 2. The iPad has a much larger screen then the iPhone so now you will be building apps with custom screens and layouts...

I think the biggest problem with the Android marketplace is that unless you are in Austria, France, Germany, Italy, Japan, Netherlands, Spain, United Kingdom or United States you cannot actually sell your apps since you cannot set up a Google Checkout account! No such problem with the Apple App store...

Not to mention that the hardware available to the iPad is probably going to be considerably better than the hardware on an iPhone.

All those iPhone developers who previously only had to worry about the iPhone and iPod touch now have a third to add to the mix. And as more versions of each get released the landscape gets worse and worse. Android may have come out of the gate with a more difficult landscape but the App Store will not always be immune either.

While CPU power differences could make a big issues, especially for games, I still say apple's fixed layout system is stronger.

You load up a new screen with a call that specifies the layout file (called a XIB) on iPhone. You can then feasibly have different layouts for iPad and for 320x480 phones.

I could easily support 5 of those. With a layout manager, you have to LOOK to see if it turned out well on the platforms (of which there are already 5-8 you care about, many times more than iphone).

What android needs, is a gui builder.

Actually, I don't think many will.

For the ipad, if you don't explicitly support the larger layout, you just get a smaller app in the middle of the screen that's still picture perfect.

And for IB, if you chose to target the iPad itself, you can just make a second XIB file that has your iPad layout for each screen, then load them up depending on hardware. It will be slightly more work, but it will still be backed by the GUI tool, and it will still be pretty easy. You aren't forced into layout manager.

As far as iPodTouch iPhone differences, those are really small for the perspective of most apps, or are total deal breakers. Either way, you're usually not doing much accommodation.

There's also a technical reason. They use their own audio toolkit which evolved out of Chuck, which Ge developed as his PhD thesis.

This would be a bear to port to Android. It would either require a complete rewrite or they'd have to use one of the weird NDK/Dalvik VM layer hacks that may or may not be officially supported.

> lynch-pin

The word they're looking for is "linchpin".

Reply on news.ycombinator.com