It's Insanely Hard to Make a Kick-Ass iPhone App | Hacker News Reader

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

georgesaines.com

137 pointsgsaines90 comments

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 any reviews for these apps, it's hard to imagine they spent much time on marketing, even just sending some free copies to bloggers to get their feedback and see if they might review it.

I'm not saying it's easy to hit points 1-3 above; it's not. But I wonder if a lot of indie app developers threw together something crappy in a few weekends of work because of all the stories out there about the big money being made, and then when it failed to materialize for them, they just gave up.

The App Store has gotten millions of people to collectively pay billions for software made by indie developers, which is amazing. But it's still a marketplace and the normal rules of any marketplace apply.

I would love for an experienced iOS developer making money to tell me if I'm wrong, and why.

I'm an indie developer on Android, just starting to make an iOS version of my first app. My app is very well polished (look here http://www.pillowfightgames.com/jargoneer/) but it's still insanely hard to do marketing-- probably because I have no idea what I'm doing yet. Although the overall quality level of many apps isn't very good, good quality is still not enough to ensure good sales. Marketing is key, I think. I hope.

Ah, just searched the iOS store for Jargoneer after watching the video. Is there a mailing list or any way to find out when it's released? Looks awesome.

Hey, judging by the video I don't agree that your app is 'very well polished'. Check out Cut the Rope, that's the kind of polish that is expected from an App Store game.

Suggestions:

- Add a tweening for picking up and dropping letters

- centering of the board should happen automatically

- put the restart button somewhere else. It looks weird when you drop a letter on top of it and it appears behind it (e.g. the 'm' in 'seem')

- can't really tell from the video whether you already did this, but implement iPhone-like scrolling w/ momentum and bouncy behavior

I think the app is indeed polished. It looks really good. But you do have a point in that users, specially iOS users, expect a lot of feedback from the app in the form of animations. I remember reading the guys from @mikamobile talking about how they even added a little bounce animation to the characters of Battleheart (http://itunes.apple.com/us/app/battleheart/id394057299?mt=8) when the user selects them with a tap. That's something you barely see because the character is under your finger, but it speaks for the amount of animation feedback necessary for a game to look "amazing" in the eyes of a current iOS user.

The market was highly profitable when it was small supply / big demand and you had good odds that Apple would hand you tons of visibility. Now it's big supply with a terrible signal to noise ratio.

To succeed, it seems that you now either need a mountain of luck, or a killer marketing engine and a fair amount of luck. Mathematically, it seems unattractive compared to other ways of applying the same time and skills unless you have something you're obsessed with building and want to produce irrespective of the outcome probabilities.

E.g. a $1.99 app pays at $1.393, so you need to move 34893.75 paid copies in order to clear a $50,000 gross. For SaaS and the same target, you only need 208.33 customers at $20/mo. The capture difficulty is not identical between cases - but if you have good marketing and are assuming serendipity on either side, it's quite feasible to hit 208 customers. Furthermore, it's often easier to grow once you get there, and it's quite possible to charge at much more than $20/mo/customer.

Mobile apps are great, but not a "for profit" activity for me. I'm all for doing them for fun or ad hoc, and if that takes off - great. But it seems to be a very difficult business model compared to applying similar resources elsewhere.

I mostly agree, but take it from voice of experience, having web application available does not magically lead to two hundred people giving you their CCs and sticking around for a year. You have to roll up your sleeves and market. This is often much, much harder than making the actual application.

(I think the App Store gets a lot of ink because people have this notion that Apple does the marketing for devs like you. Which is true, in approximately the same sense that the MBA does marketing for basketball players like Shaq.)

Magically, no. But given the same marketing resources behind either, the SaaS case seems to be more reliably attainable. Or stand-alone software. Or contract work.

For SaaS, it's also important to model things like trial conversions, turnover, etc. which don't appear in a single-sale case. There are a lot of differences. But the odds still seem better there.

And of course I am completely overlooking the "what about ads" question, mainly because you need a ton of installs before that starts being a significant amount of money. Better than not, helps feed conversions, but doesn't change the equation for me.

This may be true for mass-market apps, but we have had a lot of success selling high quality, useful, niche-market apps priced $5 and up. The App Store makes it insanely easy for people to buy something that seems useful to them, whereas they would at least think twice before paying for a webapp subscription.

Somewhat in the same vein... a friend of mine teaches ESL classes for foreign US university students. He made a pretty basic app - it's not polished but it's perfectly functional - to help his students study vocab/tenses/etc. I forget now if it was free or $0.99, either way he didn't actually have that many downloads since it was only designed for his class.

That said, the students loved it. And, he could also update the app as the course went along. Finally, although he only made enough through App Store sales to maybe go out for a nice meal, it translated into promotions, bonuses and the like. So ultimately, it paid off.

My main point is: in addition to selling niche apps at a premium, there's also the opportunity to develop cheap/free apps that otherwise help you move ahead within a niche market.

I been a completely self sufficient iOS developer(i.e I make a living from selling my own apps) for the last 3 years and I can't disagree with you.

When I initially started 3 years ago maybe you could get by with just meeting 2 of the 3 criteria you mentioned. My apps at the time were useful and easy to use, but not really beautiful.

The free version of one of these apps was getting about 400-500 daily downloads. After a much needed UI update (and one to the corresponding paid version) daily downloads jumped to more than 3000 a day. No promos, no divine Apple intervention, just Polish Polish Polish.

My hat is off to you.

5 of the 6 really good iOS developers I know personally work for clients. The 6th works for a mobile startup and has turned more into a manager.

However, most of them are getting into product as they have done enough consulting to see it is just like a normal job in many ways, no ownership.

I will buy your app later, look forward to showing it to some friends who dabble in music.

I would say my puzzle game ( http://itunes.apple.com/gb/app/combination/id300288142?mt=8 ). It got good reviews from people who played it, a good review on ArsTechnia ( http://arstechnica.com/apple/reviews/2009/04/minireview-comb... ) and was 99 cents. I only sold a couple of hundred, and after months of trying to get more publicity and sales I gave up and made it free.

I just downloaded it. It's a "simple" but nice game. I'm playing it right now. Thank you (:

Hey, I bought this after the Ars review. Thank you for your work on it! I got well more than 99 cents of entertainment value out of it.

I'm curious: did you make the puzzles by hand or generate them algorithmically?

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 and servers, instead of the $100/year cap from Apple!)

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.

Cool. I'll wait for it (:

It is a lovely little game. I think the first problem is in your marketing script. You call out negatives (doesn't have plot, soundtrack, etc) right away. I actually was expecting a silent game from this. Instead it does have sound effects, even if minimal. Regardless I don't think drawing attention to the negatives helps you. I also think the hole and wall graphics aren't helping sell it - they don't 'fit' all that well in my opinion.

Despite that I do think you prove the point that the previous poster requested. Unfortunately yours is one of many examples of well-done apps that doesn't get traction.

Do forgive the critique, I hope it will be helpful to you in going on to make ever more amazing apps. And I'll curtail my suggestions here. :)

No, they are very welcome. I learnt an awful lot about how to make a very good 'core' game engine, and how important everything else is (in some ways, unfortunately, more important).

One day I'll hopefully manage to make a new game, with both parts done well.

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 got responses from app review sites that wanted me to give them money in exchange for a review.

I made a trailer that has gotten 2,700 views (http://www.youtube.com/watch?v=Ctsk1QVs8OI). Almost all hits came from a video a friend and minor internet celebrity made for me. His video has 14,000 views. http://www.youtube.com/watch?v=rFn6eW2Kb0g

I fully admit my app is a niche app, but I think it's worth more than $420. Sites like Gizmodo have run "Best Cocktail Apps" and Apple regularly lists "Martha Stewart Cocktails" in Staff Favorites for iPad. It has approximately 12 total recipes but lots of high quality, high res images.

This may sound harsh, but, from the screenshots, your app would fall in the fugly category. On the cocktail screen, you use a bunch of fonts and clashing colors. At first look, I thought the "Tall" text thingy is a slider for glass size. It isn't.

Compare with the Martha Stewart app. It is extremely polished and the photos look gorgeous.

Harshness is fair and appreciated. It's not particularly beautiful and it has some usability issues. It's lack of success isn't a total shock, but it is certainly disappointing. The minimum bar for entry right now on iOS is pretty damned high.

Sorry to be harsh, but I have to agree with ovi256, I don't think your app looks beautiful. In particular, your fonts look boring (Arial?), there needs to be some small padding for the ingredients on the Random page, the neon-lighting on the borders looks a bit ugly, too many different colors seem to used on various pages....

I am not a designer, but you should get one to give you some suggestions. In any case, I just bought your app......happy to help out a fellow HN-er :) Hopefully this will help improve my cocktail-making skills.

PS> Check out a book called Tapworthy.

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 generates a list of potential drinks.

Or at least simplify the roulette selection to: primary component, style (cocktail, mixer, shooter, etc) and difficulty.

e.g. I have Whiskey, I want a cocktail and I don't want to spend a lot of time straining and cutting fruit.

"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.

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.

My iPhone app http://www.facemouth.com.

Polished and went nowhere. Breaking the top 25 for an indie dev is hitting the lottery. It takes a big Ad budget and great PR.

That seems pretty novelty.

I think a lot of the newer "social" free apps fall into this category, like that Oink menu item review thing. It's polished, a good app, and theoretically useful, but I wouldn't be surprised if it just dies off.

> 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% of apps.

The software game industry is wrong too.

Abstraction is a good thing, not a bad thing. Abstraction helps us write better code, and can help improve performance. Abstraction is not something to sacrifice for performance; in general sacrificing abstraction hurts performance because the bottlenecks are things like humans understanding what's going on, being able to write good algorithms which is harder with lower level code, and how long it takes them (so how much time is left over to analyze and fix code bottlenecks).

Low level languages waste time while making things harder on programmers. And they do this to no particular benefit.

None of this is to say that Objective C is terrible. It's certainly a lot better than C or C++. It has some good abstraction capabilities. But there is absolutely no reason we couldn't use a higher level language on mobile devices and get better performance for less developer time.

(The biggest real obstacles are things like the unpopularity of lisp -- it would, sadly and irrationally, mean less iOS devs and hurt Apple -- and the lack of high quality programmers who understand these things available to hire to make it.)

How is Objective-C a lot better than C++?

What do you mean by "the software game industry is wrong too"?

Objective-C has a very sweet expressivity/complexity ratio.

1) Objective-C is a very dynamic (think Smalltalk), less cluttered and more nicely designed language than C++, that can just as easy fall back to plain fast C.

2) For writing applications, desktop or mobile, nothing in the C++ libs ecosystem comes close to Cocoa/Touch.

3) For the task under discussion (iOS apps), it's the standard that get's 100% of official support from Apple, C++ is not.

DirectX is a pretty nice lib in the C++ ecosystem. OpenGL is comparable but I'd argue DX usually leads the cutting edge of graphics capabilities.

Yes, it is. But on mobile at least, I don't think there is much difference, is it?

I mean, if Windows Phone 7 uses DirectX, that is, compare to OpenGL ES.

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.

Performance bottleneck is a big issue, specially when you consider the level of graphics and AI in games these days. It is insanely clever, and would require parts of your game to be tuned in hand coded assembly, most games developers regularly hand code AI in inline assembly. The low level thinking is perfectly right, Games like mario,contra and others were even possible on a 8 bit machine with sound and graphics game loop and some AI because of assembly. Abstraction is good but not always. At some places you have to do a tradeoff. Also try writing a GLSL shader in java and then in Obj-C,C or C++ you will know how much better the latter are. This is why abstraction is not a good thing always.

Lisp is great i too agree even i like lisp very much, but a large part of the documentation available for Obj-C/Cocoa/Cocoa-touch is for Obj-C. That too apples documentation on the language and framework is the best available on the internet. Also Obj-C is a great language it is very similar to smalltalk and if you know smalltalk, Obj-C would be a joy to program in. Infact i felt Obj-C to be very similar to ruby conceptually.

> most games developers regularly hand code AI in inline assembly

This goes against any game company I worked. If anything, many are moving the AI code to scripting. Last company I worked had all the AI done in UnrealScript. Before was a mix of UnrealScript and C++ and previous was C++ with bits of lua mixed.

Never did I saw a line of assembly related to AI/Gameplay code in these games. (I was a AI programmer for about 4 years before leaving the industry in 2009)

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 be neatly divided into broad sections of performance critical and non performance critical code, then you can save the C for the bottlenecks. But it's hard to know ahead of time where those bottlenecks will be, nowadays even more so with highly interactive mobile apps. Look at all the trouble Google have had making Android scroll smoothly for example.

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.

> 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.

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.

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.

I don't think you understand what's going on. You are ignorant of what used to be standard arguments here that I wouldn't actually have to explain to you (PG has explained a lot of it, HN and Viaweb sure weren't written in C or a C variant). And which I don't really care to explain to you.

I don't think I do understand, no. What does Hacker News not being written in C have anything to do with the discussion? Weren't we talking about iPhone apps?

Maybe I am wrong, I'm always happy to hear a different perspective at least.

HN is written in lisp, like Viaweb, because lisp is better, not just as a matter of taste. Check out some of PG's lisp advocacy writing, or some (very) old HN discussions, if you're interested.

And yet iOS still seems justified (based on its competition) in eschewing garbage collection to avoid stuttering; iOS apps that display a lot of data routinely have to go to surprisingly annoying lengths to maintain 60fps[1]; there are several different runtimes that promise to let you write iOS apps in various high level languages (Flash, JavaScript, C#, etc.) but invariably most of the demo apps are laggy or buggy (and games often ship with much higher hardware requirements than the norm for the platform, which probably affects battery life as well).

The C family sucks, but it's not nearly as clear as you imply that there's a better realistic alternative.

[1] http://blog.atebits.com/2008/12/fast-scrolling-in-tweetie-wi...

I disagree with two of your three points:

(paraphrasing, fairly I hope)

> Objective-C is too much work/too low-level for your app/required because the hardware is limited.

Disagree. I wouldn't be disappointed to see solid Cocoa bindings in another approved language, but any programmer can learn C, and should. ObjC is a superset of C, and Cocoa is a beautifully consistent framework. The brackets might take a day or two to get used to, but they pretty much disappear after that. The much talked-about memory management model is not nearly as daunting as bloggers make it sound.

> Designing hugely complex monolithic apps is difficult on the iPhone.

Well, OK. I don't disagree with that entirely. But design is always serious work, information architecture is an art and science, especially for highly complex applications. That said, your app is not Photoshop and a good designer can solve your problems. Photoshop on an iPhone would be Difficult. So would XCode.

> App store discoverability is poor, marketing around launches is unpredictable, betas and limited releases are complicated or unworkable, audience feedback is a big problem.

Agreed 100%...! :)

Good luck with your dev!

Photoshop is modular, not monolithic.

Designing a large monolithic anything is insanely hard. It's often best to design around it.

"It's insanely hard to make a kick ass _____"

One of the reasons mobile design is so hard is because you have to use 100% of the screen. Not only do you need to make it look good, but you also need to squeeze the resources of the phone. You have to worry about battery life, network usage, and storage space. It's a challenge, but it makes the end result a lot better.

The same rules really should apply to development on any platforms. Keep it light, simple, and focus on one thing.

>>"because you have to use 100% of the screen"

I think the that kind of restrain on the user would make work on native mobile development side easier. All you would have to deal with is 2x views (portrait & landscape) vs all the possible combinations of web screen sizes.

>> 2x views Yeah, your right. Even if you consider Android, it becomes just a bit more complicated.

Your point is very true for development (It's what I love about iOS) but for design it's a challenge.

It really makes you focus on the one thing. Take gmail for example. On the web, I can do 20 different things, but in iOS the choices are limited to 3-4. It's really hard to make things simple, so where you make the compromises is the challenge.

I was trying to make the comparison to iOS (theoretically iphone/itouch) vs web. Whether you focus on a single native mobile environment or multiple, I kinda think the scales at least from the UX design perspective if not also the development side.

"For a generation of coders accustomed to limitless managed memory, high-level programming abstractions, and thousands of deeply functional opensource libraries, mobile is a step back to the Byzantine world of Commodore 64s."

This made me chuckle. Maybe if you define "generation" as "this year's college output" then you might be right, but if we're talking "generation" as in the past lifetime of software development then it's nowhere close.

Only in the last 5-10 years have we seen the rise of the well put together framework.

Also, I have no experience with iOS, but the Android framework is pretty damn nice from the perspective of somebody who actually lived through the C64 days!

I don't think it's a lamentation over framework per se, but rather a step back from the web-hysteria of a few years ago, where you can pretty much, with a lot of elbow grease (aka Perl) tie together component A with component B and feed it into component C to do something cool/wicked/useful, where they're all giant open source projects.

Think of all the crazy things we did pluggin ImageMagick into PHP backed by giant MySQL instances.

This is no longer really possible with mobile. I recently pulled in some image recognition libs to my app, and it's an extreme struggle keeping a large, legacy, C++ lib from exploding all over a mobile device. We really are stepping far, far, back from the previous trend of writing code as if the metal they run on is but a detail.

"""Think of all the crazy things we did pluggin ImageMagick into PHP backed by giant MySQL instances."""

While I agree those were easy to use, I can't think of any crazy/cool things from that era websites.

Most of the cool/useful/nice web stuff is from the Ajax/fast JS/jQuery etc era of late.

"""I recently pulled in some image recognition libs to my app, and it's an extreme struggle keeping a large, legacy, C++ lib from exploding all over a mobile device. We really are stepping far, far, back from the previous trend of writing code as if the metal they run on is but a detail."""

It was never "but a detail", it was just that web development is seldom CPU/Memory-bound. Mobile development in the main is.

Also, if you were trying to do a competent 3D game engine, back in the same era you did PHP/MySQL stuff, you'd see that the PC metal was not "but a detail" at all.

It's also a little contradictory to lament about how easy it was to "plug ImageMagick into PHP backed by giant MySQL instances" and then compare it to the difficulty of not only programming for a mobile device, but also "pulling in some image recognition libs to my app".

Not only you're attempting something much more cpu intensive and difficult than using ImageMagick/PHP for web development, something that could have been just as difficult if not more so back in your web days, but you also try it in a device with less memory/cpu. Something's gotta give, right?

That said, nothing stops you writing plain apps for mobile that just do the same stuff you did on the web. There are plenty of frameworks that basically provide you with a browser view and let you do stuff (Platinum, etc).

    Most of the cool/useful/nice web stuff is from 
    the Ajax/fast JS/jQuery etc era of late

Wikipedia, Blogger, Flickr, a bazillion forums on which I spent countless hours. Ajax/JS/jQuery are cool, however when it comes to usefulness many times they are superfluous. The old Twitter interface was a lot more usable.

    web development is seldom CPU/Memory-bound

This is only an impression because the hard work gets done by the database or other external processes that are outside of your web server. Business logic is cheap if you can delegate the actual data processing and when you delegate, of course it's going to be I/O bound. On the whole if you count every component, web applications are the biggest consumers of these resources.

    nothing stops you writing plain apps for mobile that 
    just do the same stuff you did on the web

I agree, you can also have a native mobile interface, while the whole logic is done on server. Like in the case of a chess game, you could have the minimax algorithm (or whatever) on the server, with a push mechanism to notify the client when the move is ready.

C64s weren't so bad. I remember reading an interview with, I think, Geoff Crammond (author of the class Stunt Car Racer) where he said the C64 (in comparison to the Amiga) was the last machine where you actually could know every last trick about the hardware and keep it all in your head.

I think most major colleges are still teaching C++ as the main programming language. Sure, there are classes in Python or Ruby on occasion, but I think most are still in C++. I know a lot of schools teach Java, but that's a lot more similar to C++ than it is to something like Python.

If there can be considered a "main" programming language that is taught at most colleges, and that most students spend the majority of their time with, I would say it's Java.

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 step back to the Byzantine world of Commodore 64s.

Really? An 8bit 1Mhz processor with 64Kb? Or is it a 600Mhz 32bit processor with 262,144kb. Sure it doesn't match up to my i7, but when java first came out we had Pentium 90s. The lack of ObjC library support is changing as more developers pile on, and if you go with C# then that's pretty much solved.

(As a kid in the UK, you had a ZX Spectrum, a C64 or a BBC Micro. The next gen Commodore was the Amiga. The next gen BBC was the Archimedes. The Archimedes had the ARM2. Same instruction set as an iPhone... in 1988. I shipped a game on it. 100% Assembly. Much prefer C# to hand-rolled assembly, so its not just the new kids.)

Yes but Moore's law is applied to phones differently, because battery life is as important as processing power, or even more so.

This is the reason the 600Mhz processor in your phone will have worse performance than a normal 600Mhz processor. Mhz is useless as a measure for performance and it became popular only because of marketing campaigns by Intel, when they had an edge in the Mhz race. A more useful measure (other than running unbiased benchmarks) would be MIPS (millions of instructions per second) and MFLOPS (millions of floating-point instructions per second).

For example an ARM11 from 2002 at 412 MHz was able of 515 MIPS (millions instructions per second), while a Pentium Pro from 1996 was capable of 541 MIPS at 200 MHz. Also an Intel Core i7 EE is capable of 177,730 MIPS at 3.33 GHz, while an AMD Phenom 2 X6 from 2010 is capable of 78,440 MIPS at 3.3 GHz.

Basically your 600Mhz mobile processor is not the same processor you had when playing Counter-Strike a couple of years ago. That's because it is optimized for consumption rather than performance.

While I agree with you that the instructions matter, are your numbers x86 (or arm) instructions, or are they micro-instructions that your high level instruction set is translated in to? If so, the other factor is how many micro-instructions your instruction is broken down in to.

Do you have any examples of what you've build with MonoTouch?

I've done native development for iOS, Android, and WP7, and I'd be interested to see what advantage MonoTouch brings.

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)

I've found it far less insanely hard than what you need to know to make a kick ass web app.

Is it just me or does anyone who seriously thinks any app that resembles "photoshop, but on your phone" is going to be successful really have a strange perspective on what people use their phones for?

  Photoshop’s submenus, window management, and setting 
  screens afford that software package a level of feature 
  depth I don’t believe can be achieved in a mobile 
  environment no matter how sophisticated and intuitive UI 
  conventions become.

I wonder if the author is aware of Photoshop for Android tablets - https://market.android.com/details?id=air.com.adobe.pstouch

Granted, it doesn't have all the features of desktop Photoshop, but it looks like it has a lot of the features, and it has great ratings.

A tablet only app isn't the same beast as a smartphone app. You can throw a large number of menus onto a 10 inch tablet and gain functionality rather than lose it; try the same thing on a 3.whatever iPhone and you'd have an extremely cluttered, useless app.

There's also Photoshop Express for the iPhone. It's worth looking at to see what kind of design decisions they've made. http://itunes.apple.com/us/app/adobe-photoshop-express/id331...

> But it won’t run on anything less than an iPhone 3GS.

This is a general problem with mobile given how fast the hardware is moving along. And given that the 3GS is what, ~2.5 year old hardware? I don't think that it's crazy that an app won't run on anything less (I do think it's crazy that Apple still sells the 3GS). And I think consumers also kind of expect that if they do have older (pre 3GS) hardware, things are going to be slow. Also, despite the overall evilness of American cell carriers, it is kind of helpful to us mobile developers that they do their best to enforce a 2 year upgrade cycle with hardware.

I think making anything "kick ass" is insanely hard. The depth of knowledge/creativity/intuition/etc. required to make incredible products in general is certainly non-trivial.

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.

Marketing is even harder!

Although not an iPhone app, we've spent a lot of time in both developing and marketing our iPad game. But the revenue doesn't justify building another game which we would've loved to do. Developing an app is only half the battle, the other half is marketing it and as developers we are very bad at marketing.

Our criteria for a success was: Polished Graphics, Engaging Gameplay, Sense of Humor and a Cool Trailer.

Paddle Battle for iPad:

http://paddle-battle.com/

http://www.youtube.com/watch?v=xP2gnq6z3Fc

http://itunes.apple.com/us/app/paddle-battle/id415463249?mt=...

Discovery is not the issue. The issue is keeping the app on the device. With so MANY apps new every day, the average person loses track of the new apps they downloaded, and they stop using the older ones unless they really are kick ass.

Spend less on marketing, more in making your app indispensable.

The only major problem I see here is the app store itself. Discoverability is a huge problem... It is the one that I am most shocked that Apple has done nothing about. I routinely have trouble finding apps that have been released, and it is easy to get lost in the crowd. My company has released a few apps (we contract for other guys) and it is almost pure luck which ones end up picking up steam (certainly not our best work).

I don't know the android market well... it seems to be better, but only on the margins. I am surprised that noone has come up with a better way.

There's no worthwhile "Dip" when it comes to making an iPhone app since it's become commoditized, and crowded. There's a lot of effort, luck, sweat, etc, don't get me wrong, but the cost/benefit ratio just sucks. You're better off putting that sweat to creating an enterprise app for Fortune 500 clients, or creating the next big social network.

Also, remember.. there's a lot of commotion over mobile, but in terms of monetization, it still lags behind web display, and search ads.. it's not even close.

Making an iPhone app is relatively easy compared to most app development for the history of computing. Doing it well is significantly harder, but then again so is any craft. I dare say it's quite a bit easier than writing your program on a stack of punch cards and waiting 24 hours for the output. Or for that matter, making a chair that will last 100 years.

I.T.O monetization, you can also take the route of not developing iOS apps for yourself and trying to sell them for $0.99. You can instead offer your services to mid-sized companies' marketing departments and build iOS apps for them. You won't make millions if it explodes in popularity, but what are the chances of that anyway?

As he talks about the marketing problem for small players, I've just posted an Ask HN survey for Mobile Game Developers to get some feedback on something I've been working on to help small players. http://news.ycombinator.com/item?id=3334832

For some excellent examples of apps in the vaunted league that he mentions, check out Beautiful Pixels.

http://beautifulpixels.com

The user interface is everything if you want to compete in the major leagues (e.g. top 100).

May get downvoted for pedantry, but the spelling error in the first paragraph on that page drives home the OP's point. There are so many ways to undermine yourself as an indie dev.

If your product is that good , Apple does your free promotion on its sites,partners sites and Apple ad network sites for free, App store is just as beneficial to small players as large. You just have to create something remarkable and worthwhile to catch there attention.

I think one if the most beautifully designed app loaded with desktop level functionality, yet optimized for mobile, is Intua's Beatmaker II. Amazing. One of the best apps.

The fart app guy (his app was the #2 fart app in the app store) is retired with a $4-7 million bank account.

do android developers have many of the same issues?

The quality bar is lower and the customers are miserly and fickle. For lack of a better term, iOS customers are snobs and Android customers are middle class.

What I've found difficult to navigate is that while it feels a little like the joy of programming your old C64 (or in my case, Osborne 1), the truth is you're putting your work out there and it suddenly becomes open to both harsh criticism and support expectations - even if you're giving it away for free, without advertising.

My app is for film-makers, and it's called Acacia (https://market.android.com/details?id=com.ephemerald.cameraa...), and I'll fix the bugs when I have time :)

Reply on news.ycombinator.com