It's Insanely Hard to Make a Kick-Ass iPhone App • Hacker News Board

Re: It's Insanely Hard to Make a Kick-Ass iPhone App

#81

Post by xenophanes » Fri, Dec 09, 2011, 7:12 PM UTC

MrScruff wrote: post #41

xenophanes wrote: post #24

> the reason why developers are shackled to Objective C is to make sure processes finish in human time, and this is fundamentally a performance bottleneck in mobile hardware. This is completely false. You can get good performance with high level languages like lisp. It doesn't have to look like C to be fast and to be possible to optimize it well. The whole "writing low level code is faster" mentality is WRONG for 99%…

The whole "writing low level code is faster" mentality is WRONG for 99% of apps. I read this a lot but I don't know where it comes from. For me, 'fast enough' in terms of subjective performance of an application is 'as fast as the current performance benchmark on that platform'. Anything less implies the developer has taken short cuts and creates a bad impression. On mobile devices even more so. Sure, if your app can…

> it's hard to know ahead of time where those bottlenecks will be

Exactly. So the only reasonable policy is to use a language which is fast to write, and fast to change. Then, once you have software working, test where the bottlenecks actually are and change those parts (the majority of the time this does not require writing in a lower level language, just changing the design, fixing bugs, adding compiler hints, etc...)

> In a marketplace where users will dismiss your app immediately over tiny glitches and pauses, I'd be inclined to write everything in C++ other than the Objective C stuff.

By writing in inferior languages, you are creating apps with more bugs that take up more developer time (leaving less time to fix bugs, update older apps, etc). By your own claims, this means your apps will be dismissed. It's a mistake.

Re: It's Insanely Hard to Make a Kick-Ass iPhone App

#82

Post by xenophanes » Fri, Dec 09, 2011, 7:16 PM UTC

davedx wrote: post #28

xenophanes wrote: post #24

> the reason why developers are shackled to Objective C is to make sure processes finish in human time, and this is fundamentally a performance bottleneck in mobile hardware. This is completely false. You can get good performance with high level languages like lisp. It doesn't have to look like C to be fast and to be possible to optimize it well. The whole "writing low level code is faster" mentality is WRONG for 99%…

How is Objective-C a lot better than C++? What do you mean by "the software game industry is wrong too"?

The game industry writes buggy and poorly performing (relative to how they could be) games in C++ instead of writing better and better optimized games in superior languages.

Re: It's Insanely Hard to Make a Kick-Ass iPhone App

#83

Post by Florin_Andrei » Fri, Dec 09, 2011, 7:35 PM UTC

Well, the number one reason why my iPhone is a much less useful device than it could be is that many apps are insanely slow to launch.

Dictionary.com - what do I use it for? As a non-native English speaker, sometimes I do a quick check on a word I'm not sure of. But the app takes so long to launch. It activates GPS, it connects via the Internet to download some obscure data that I don't care about, it does so many things that leave me completely indifferent... and it fails to do the one most important thing that I DO care about: find out the meaning of a word really quick. Like, right now, please.

Sure you can turn off some of the extra features (but not all), sure you can reboot iOS to make it a bit more snappy, but the app still feels sluggish. And this is on an iPhone 4.

Folks, sometimes an app is just an app. All those features that you think make the app more appealing to the customers - are just dead weight that pull it down. Please, keep the apps lean and quick.

Re: It's Insanely Hard to Make a Kick-Ass iPhone App

#84

Post by JamesAn » Fri, Dec 09, 2011, 8:17 PM UTC

buff-a wrote: post #19

But the reason why developers are shackled to Objective C is to make sure processes finish in human time, and this is fundamentally a performance bottleneck in mobile hardware. I use monotouch. Compiles to ARM assembly. Not seeing any problems. For a generation of coders accustomed to limitless managed memory, high-level programming abstractions, and thousands of deeply functional opensource libraries, mobile is a st…

The Archimedes had the ARM2. Same instruction set as an iPhone... in 1988. I shipped a game on it. 100% Assembly.

Just out of curiosity, which game was this?

(Just Another Archie programmer)

Re: It's Insanely Hard to Make a Kick-Ass iPhone App

#85

Post by CJefferson » Fri, Dec 09, 2011, 8:30 PM UTC

diba wrote: post #75

CJefferson wrote: post #70

Earlier quoted context omitted.

Thank you! Algorithmically. The game actually came out of a research project into generating and automatically ranking the difficulty of puzzle games. I have a long term plan to write a new game, with different puzzle games in it, using the same technique. The main slowness is a) Playing around with HTML5 and b) Figuring out how to make money off it (as with a webapp, you can actually lose a lot of money with hosting…

Do you have the results of that research project available somewhere?

http://www.it.uu.se/research/group/astra/ModRef10/papers/Chr...

Is a preliminary paper, we have a longer one in the works.

Re: It's Insanely Hard to Make a Kick-Ass iPhone App

#86

Post by forrestthewoods » Sat, Dec 10, 2011, 12:32 AM UTC

roc wrote: post #78

forrestthewoods wrote: post #45

Earlier quoted context omitted.

I have $420 revenue from 285 sales (started $3, dropped to $1) in 6 months from my side project. http://itunes.apple.com/us/app/alcohology/id437180278?mt=8 . Getting attention is hard. Ridiculously hard. Insanely, impossibly hard. I couldn't get a review from a single website. I submitted the app to dozens of review sites, food/drink blogs, and tech blogs and didn't get a single response. Actually, that's not true. I…

Also, compare to Cocktails+. It's more stripped down in many ways, but the overall effect is more pleasing to my eye. Also, the random feature on Alcohology is really interesting and would be incredibly useful. But why is it limited to an urbanspoon-style restaurant finder? Drink components don't seem to map well to that layout. Perhaps allow for the input of an arbitrary number of components into a "bar", which then…

"Perhaps allow for the input of an arbitrary number of components into a "bar", which then generates a list of potential drinks."

That is exactly what it does. The second line of the description states "Alcohology is specially designed so you can see what cocktails your home bar can actually create" and the 3rd and 4th bullet points are "Customizable ingredients for your bar. Toggle to see all recipes or only recipes your bar can make"

Your comment has made it obvious that I have utterly failed in getting that point across. I'll re-work the description and screenshots to change the sales pitch.

Re: It's Insanely Hard to Make a Kick-Ass iPhone App

#87

Post by MrScruff » Sat, Dec 10, 2011, 11:59 AM UTC

xenophanes wrote: post #81

MrScruff wrote: post #41

Earlier quoted context omitted.

The whole "writing low level code is faster" mentality is WRONG for 99% of apps. I read this a lot but I don't know where it comes from. For me, 'fast enough' in terms of subjective performance of an application is 'as fast as the current performance benchmark on that platform'. Anything less implies the developer has taken short cuts and creates a bad impression. On mobile devices even more so. Sure, if your app can…

> it's hard to know ahead of time where those bottlenecks will be Exactly. So the only reasonable policy is to use a language which is fast to write, and fast to change. Then, once you have software working, test where the bottlenecks actually are and change those parts (the majority of the time this does not require writing in a lower level language, just changing the design, fixing bugs, adding compiler hints, etc.…

By writing in inferior languages, you are creating apps with more bugs that take up more developer time (leaving less time to fix bugs, update older apps, etc). By your own claims, this means your apps will be dismissed. It's a mistake.

I'm not sure what you mean by inferior language. By this reasoning pretty much all of the best iOS and MacOS applications are developed with inferior languages...

I don't really see why an experienced C++ developer would create any more bugs than one developing in any other language. Most of the difficulties people complain about (explicit memory management for example) are massively overstated and not in any sense a problem for anyone other than a novice.

Re: It's Insanely Hard to Make a Kick-Ass iPhone App

#88

Post by localhost3000 » Sat, Dec 10, 2011, 4:49 PM UTC

forrestthewoods wrote: post #45

ryanwaggoner wrote: post #7

Are there many examples of iPhone apps that are simultaneously (and somewhat objectively): (1) beautiful, (2) easy to use, and (3) useful, that still don't go anywhere? I've been trolling around the app store for awhile trying to understand the market and what I see are tons of novelty apps, fugly apps (by anyone's standards), buggy apps, and apps that break usability in all kinds of ways. And judging by the lack of…

I have $420 revenue from 285 sales (started $3, dropped to $1) in 6 months from my side project. http://itunes.apple.com/us/app/alcohology/id437180278?mt=8 . Getting attention is hard. Ridiculously hard. Insanely, impossibly hard. I couldn't get a review from a single website. I submitted the app to dozens of review sites, food/drink blogs, and tech blogs and didn't get a single response. Actually, that's not true. I…

it's a niche app but it is also a very crowded niche. I've seen dozens and dozens of cocktail recipe apps. I pay pretty close attention to this market b/c i'm in it but have gone at it from an entirely different angle (if interested, see http://itunes.apple.com/us/app/bostonflip/id451503483 which i believe passes the 'fugly' test?). we're only servicing boston metro area at the moment.

Re: It's Insanely Hard to Make a Kick-Ass iPhone App

#89

Post by xenophanes » Sat, Dec 10, 2011, 7:40 PM UTC

MrScruff wrote: post #87

xenophanes wrote: post #81

Earlier quoted context omitted.

> it's hard to know ahead of time where those bottlenecks will be Exactly. So the only reasonable policy is to use a language which is fast to write, and fast to change. Then, once you have software working, test where the bottlenecks actually are and change those parts (the majority of the time this does not require writing in a lower level language, just changing the design, fixing bugs, adding compiler hints, etc.…

By writing in inferior languages, you are creating apps with more bugs that take up more developer time (leaving less time to fix bugs, update older apps, etc). By your own claims, this means your apps will be dismissed. It's a mistake. I'm not sure what you mean by inferior language. By this reasoning pretty much all of the best iOS and MacOS applications are developed with inferior languages... I don't really see w…

Because lower level languages mean more bugs.

Not all languages are equally good.

Hacker News sure has changed...

Re: It's Insanely Hard to Make a Kick-Ass iPhone App

#90

Post by MrScruff » Sun, Dec 11, 2011, 9:07 PM UTC

xenophanes wrote: post #89

MrScruff wrote: post #87

Earlier quoted context omitted.

By writing in inferior languages, you are creating apps with more bugs that take up more developer time (leaving less time to fix bugs, update older apps, etc). By your own claims, this means your apps will be dismissed. It's a mistake. I'm not sure what you mean by inferior language. By this reasoning pretty much all of the best iOS and MacOS applications are developed with inferior languages... I don't really see w…

Because lower level languages mean more bugs. Not all languages are equally good. Hacker News sure has changed...

You didn't address my point. Pretty much all of the best known and regarded applications are written in a C variant, including the browser you're viewing this on. On the iPhone, pretty much all of the best applications are written in a C variant.

Because lower level languages mean more bugs.

That's not actually a magical rule you know. The primary difference is that it's slower to develop in lower level languages. But users generally don't care about that.

Hacker News sure has changed...

Great argument.