Mobile app startups are failing like it’s 1999(andrewchen.co)
andrewchen.co
Mobile app startups are failing like it’s 1999
http://andrewchen.co/mobile-app-startups-are-failing-like-its-1999/
54 コメント
It's really hard to push out code 2-3 times / week when you have 7-10 days review time for every change
Things have actually gotten worse for us developers. I've noticed now that I'm taking a significant hit on App Store views when I release a new version.
My best guess is that this is due to the reviews being reset on each release. If I'm out a couple of weeks of growth due to each new release I have every incentive to release less frequently.
My best guess is that this is due to the reviews being reset on each release. If I'm out a couple of weeks of growth due to each new release I have every incentive to release less frequently.
my impression was that freshness and # of updates per release has an affect on ASO.
I think it also has to do with the expectations users have these days. People use well polished apps all day long, so to push out a first iteration of a new app, for users (even early adaptors) to take the app "serious" it needs to have a certain level polish. Adding polish to an app is what takes most time.
There is no date on this post or date in the URL. This could have been posted in 2001, 2002, 2003, etc...
OP here. This was published Aug 15, 2012.
[deleted]
The publish date is in the source code.
It's probably around 2009 - there's a reference in the first paragraph to 'the last 10 years'
Because the app store is turning out to be one of the worst things that has happened to the web. An entire generation of startups have poured their dreams into a disaggregated, narrowly distributed store model.
The dreaminess of the iphone is finally wearing off, as we realize we can't solve really interesting problems within its restrictions.
1. Controlled, central distribution
2. No natural interconnectivity
3. No push update model
4. No community or central navigational paradigm other than iOS
5. No ability to distribute a genuinely new UX model
6. No real hardware access
The dreaminess of the iphone is finally wearing off, as we realize we can't solve really interesting problems within its restrictions.
1. Controlled, central distribution
2. No natural interconnectivity
3. No push update model
4. No community or central navigational paradigm other than iOS
5. No ability to distribute a genuinely new UX model
6. No real hardware access
Serious question: assuming all the restrictions you dislike were to be magically lifted, say, tomorrow: tell me what apps you'd see that you are currently not seeing and how they'd affect your life.
For me, everything you mentioned is unfortunate and a massive pain in the ass for developers, but not anything that holds back the floodgates of anything terribly exciting. (Maybe it is just my lack of imagination?)
For me, everything you mentioned is unfortunate and a massive pain in the ass for developers, but not anything that holds back the floodgates of anything terribly exciting. (Maybe it is just my lack of imagination?)
Google now like streaming ui, widgets that are in a useful, web app install, interactive notifications, facial unlock, I could go on and on
But "mobile is the future!"
The idea that mobile is categorically the future of everything has been on my valley echo chamber meme death watch list for years.
Everything you say is true. Fundamentally I think it can all be distilled down to:
- "Feudal" platforms -- total control by a single vendor, essentially like a game console rather than a "real computer."
- Heavily restricted both by app store policies and by technical limitations like battery life, etc. Put these together and whole vast areas are just off limits.
- Tiny screen and limited UI -- it's great for quick interactions, but terrible for anything deep or engaging.
Mobile is tremendously useful, but it is not going to replace "everything."
The largest, most profitable, and most transformative company to come out of the web (so far) was Google. For Mobile I personally think it's going to be Uber, since that particular use case is just such an insanely awesome killer app. It's impossible to say for sure, but with the web there was only one Google. Not sure there's going to be another Uber. (Note that I'm not counting Maps, the other killer app for mobile, because that's typically bundled so it's not a third party opportunity.)
The idea that mobile is categorically the future of everything has been on my valley echo chamber meme death watch list for years.
Everything you say is true. Fundamentally I think it can all be distilled down to:
- "Feudal" platforms -- total control by a single vendor, essentially like a game console rather than a "real computer."
- Heavily restricted both by app store policies and by technical limitations like battery life, etc. Put these together and whole vast areas are just off limits.
- Tiny screen and limited UI -- it's great for quick interactions, but terrible for anything deep or engaging.
Mobile is tremendously useful, but it is not going to replace "everything."
The largest, most profitable, and most transformative company to come out of the web (so far) was Google. For Mobile I personally think it's going to be Uber, since that particular use case is just such an insanely awesome killer app. It's impossible to say for sure, but with the web there was only one Google. Not sure there's going to be another Uber. (Note that I'm not counting Maps, the other killer app for mobile, because that's typically bundled so it's not a third party opportunity.)
Slightly off-topic, but regarding shininess of iphone.
My biggest issue with iOS it has no usable web browser. Zooming doesn't reflow column text to screen width. IMHO, the single most important feature in a mobile phone web browser.
So now web site authors have started to make these horrendous mobile versions with zoom-locked viewports.
Opera is still the only way to go for mobile phones. Note, not Opera Mini, but Opera.
So far this issue has kept me away from iPhone.
My biggest issue with iOS it has no usable web browser. Zooming doesn't reflow column text to screen width. IMHO, the single most important feature in a mobile phone web browser.
So now web site authors have started to make these horrendous mobile versions with zoom-locked viewports.
Opera is still the only way to go for mobile phones. Note, not Opera Mini, but Opera.
So far this issue has kept me away from iPhone.
> Zooming doesn't reflow text
I'm a bit confused. Why would you want that? Shouldn't zooming just make things bigger?
I'm a bit confused. Why would you want that? Shouldn't zooming just make things bigger?
If I zoom, it doesn't mean I want to be forced to scroll horizontally back and forth. I don't understand why anyone would want to do that.
When text reflows while zooming, you can choose exactly the size that is most readable for you.
For example, if I read while walking, I usually make text size larger, because it improves reading speed.
And you can comfortably use desktop versions of websites.
When text reflows while zooming, you can choose exactly the size that is most readable for you.
For example, if I read while walking, I usually make text size larger, because it improves reading speed.
And you can comfortably use desktop versions of websites.
So you want zooming to act like Control++ and Control+- does in desktop Chrome/Firefox?
Yes - that's an excellent way to put it. Make zoom work like it does in a desktop browser. The one thing I can appreciate though is double tap to get rid of cruft by focusing in on text.
Not exactly, but that's closer. Use Opera for Android to see what I mean. Be sure to enable reflow related options. It's pretty great.
The difference is mainly intelligently limiting DIVs (columns) individually to the available viewport horizontal space. Ctrl-plus and Ctrl-minus does not do this, it tries to fit whole width.
Shame that other mobile browsers have made it their mission to imitate whatever mobile Safari is doing.
The difference is mainly intelligently limiting DIVs (columns) individually to the available viewport horizontal space. Ctrl-plus and Ctrl-minus does not do this, it tries to fit whole width.
Shame that other mobile browsers have made it their mission to imitate whatever mobile Safari is doing.
Zooming in without reflow, makes things bigger, but means you now have to swipe to move the viewport over the text.
It can be an annoying feature, though there are other things that can be annoying about actually reflowing the text as well, as a lot of the mobile layouts are already cramped, and as such zooming could cause other issues.
It's a situation where you're given several really bad options, and you need to pick one you feel is most optimal. Locking the viewport to a specific zoom-level to prevent the side-to-side swiping is an accessibility issue, but makes the layout simpler.
It can be an annoying feature, though there are other things that can be annoying about actually reflowing the text as well, as a lot of the mobile layouts are already cramped, and as such zooming could cause other issues.
It's a situation where you're given several really bad options, and you need to pick one you feel is most optimal. Locking the viewport to a specific zoom-level to prevent the side-to-side swiping is an accessibility issue, but makes the layout simpler.
> can be annoying about actually reflowing the text as well, as a lot of the mobile layouts are already cramped, and as such zooming could cause other issues.
No, it's fine, as long as it reflows individual columns to full screen width. Reflowing whole width (multiple columns side by side) is not useful (like what desktop browsers do) exactly because it'd get too cramped on a mobile device screen.
No, it's fine, as long as it reflows individual columns to full screen width. Reflowing whole width (multiple columns side by side) is not useful (like what desktop browsers do) exactly because it'd get too cramped on a mobile device screen.
Android has a couple of these things.
I fail to see how this stopped Uber.
I built my first mobile app this year (iOS) and I was appalled at how bad the tooling and development workflow for mobile was. Swift is a disaster, the app store approval process feels like going back 10 years in a time machine, debugging XCode is like trying to solve the riddle of the Sphinx, testing is hard, a reloaded dev workflow is non-existent... It's no wonder startups can't get out the door and quickly iterate on mobile.
It's crystal clear that using web tooling and compiling Javascript to native components is the way forward here. It's just that tools like PhoneGap, Titanium, Cordova ... were half-baked solutions and never really excited me. This is why React Native is such a game-changing technology. If a startup can get to iOS and quickly iterate without being held back by XCode/Swift it's a massive competitive advantage. Let other companies spend millions and 9 months hiring 'iOS only' developers, and struggling to get a V1 to market when you can take just your existing model layer which is already rendering JavaScript somewhere anyway, and have it target iOS native without missing a beat.
Really interested to see the fallout from React Native, especially once the Android library is released later this year.
It's crystal clear that using web tooling and compiling Javascript to native components is the way forward here. It's just that tools like PhoneGap, Titanium, Cordova ... were half-baked solutions and never really excited me. This is why React Native is such a game-changing technology. If a startup can get to iOS and quickly iterate without being held back by XCode/Swift it's a massive competitive advantage. Let other companies spend millions and 9 months hiring 'iOS only' developers, and struggling to get a V1 to market when you can take just your existing model layer which is already rendering JavaScript somewhere anyway, and have it target iOS native without missing a beat.
Really interested to see the fallout from React Native, especially once the Android library is released later this year.
I don't really buy this.
Facebook for example is releasing new versions every 2 weeks and every day I have updates for at least 6 of my apps. I also have built at least 10 apps for enterprise companies and provided you have decent CI have been able to turn around updates in less than a week. It is a different workflow that's for sure. As for Swift being a disaster well that's debatable.
Javascript and other Write Once, Run Anywhere approaches have always been shown to be flawed. They force the lowest common denominator. And on a platform like iOS where users are very picky about polish they will punish developers who have apps that don't feel right.
Facebook for example is releasing new versions every 2 weeks and every day I have updates for at least 6 of my apps. I also have built at least 10 apps for enterprise companies and provided you have decent CI have been able to turn around updates in less than a week. It is a different workflow that's for sure. As for Swift being a disaster well that's debatable.
Javascript and other Write Once, Run Anywhere approaches have always been shown to be flawed. They force the lowest common denominator. And on a platform like iOS where users are very picky about polish they will punish developers who have apps that don't feel right.
Except they don't really force the lowest common denominator. It's not too hard to write a plugin for cordova. Additionally,
React Native isn't write once run everywhere - it's learn once run everywhere. And it interfaces with the real native widgets and has the javascript on it's own thread. That's anything but feeling right. It's more like Javascript bindings than a totally new paradigm.
React Native isn't write once run everywhere - it's learn once run everywhere. And it interfaces with the real native widgets and has the javascript on it's own thread. That's anything but feeling right. It's more like Javascript bindings than a totally new paradigm.
> Javascript and other Write Once, Run Anywhere approaches have always been shown to be flawed. They force the lowest common denominator.
That's nonsense. Javascript is certainly missing some features for mobile, but it's not because it is designed for "the lowest common denominator". It's because it's an open platform, and the standards committees and browser developers are really slow to keep up with all the devices that we have now.
Unity, on the other hand, works extremely well. Adobe AIR works well too. There are really awesome games made using both platforms, arguably the toughest kinds of applications to make "feel right". You can't just say the "Write Once, Run Anywhere" approaches are flawed when there are thousands of counter-examples on the app stores right now.
That's nonsense. Javascript is certainly missing some features for mobile, but it's not because it is designed for "the lowest common denominator". It's because it's an open platform, and the standards committees and browser developers are really slow to keep up with all the devices that we have now.
Unity, on the other hand, works extremely well. Adobe AIR works well too. There are really awesome games made using both platforms, arguably the toughest kinds of applications to make "feel right". You can't just say the "Write Once, Run Anywhere" approaches are flawed when there are thousands of counter-examples on the app stores right now.
You can access the native objects and interact with them in javascript using Tint (essentially node.js + native-bridge + ease-of-use-wrapper). A little different then "run-in-a-webkit-with-C++-callbacks" mentality (e.g., phonegap, node-webkit), or facebook's "branded-programming" with react native.
How is react facebook "branded-programming"? Sure they released it but it's open source and is quickly becoming a extremely wide spread standard.
I agree about React Native, it basically makes JS a first class language on the platform. I was a native only guy for as long as the platforms have been around. But the chrome dev tools debugging, ability to quickly and easily share code between the web and mobile, and the quick dev cycle is really powerful.
I really disagree that swift is a disaster, for the most part it's a extremely well designed language. Great functional tools, great performance, and playgrounds plus a useable repl were all huge steps for the iOS platform.
Swift is awful to use in practice.
It once took me 24 hours to parse a JSON response into a Swift object. In ruby you can get a ruby object from JSON by calling JSON.parse(data)... that's it. It takes one second. In Swift it's a nightmare, it can take you a full day. Who the hell has time for that? Startups are all about speed, who wants to waste a day trying to parse JSON when it's a one-liner in literally every other language ever made.
I also hate using mutable objects for my data model. Swift allegedly solves this with Structs but they're really hard to use in practice. Want to pass a struct through a Notification? Too bad, needs to inherit from NSObject so guess you're stuck using mutable objects?
Swift might be a well designed language from an academic standpoint. I have no idea, I'm new to programming. But I can say for sure that it's horrible to use compared to other languages that I've used in production (Ruby, Clojure, Javascript). I would bet anything that being able to use any language/workflow of your choosing and compiling to iOS native through JS will be a better business decision than coupling yourself to XCode/Swift and whatever hacks you build to make the workflow less painful.
It once took me 24 hours to parse a JSON response into a Swift object. In ruby you can get a ruby object from JSON by calling JSON.parse(data)... that's it. It takes one second. In Swift it's a nightmare, it can take you a full day. Who the hell has time for that? Startups are all about speed, who wants to waste a day trying to parse JSON when it's a one-liner in literally every other language ever made.
I also hate using mutable objects for my data model. Swift allegedly solves this with Structs but they're really hard to use in practice. Want to pass a struct through a Notification? Too bad, needs to inherit from NSObject so guess you're stuck using mutable objects?
Swift might be a well designed language from an academic standpoint. I have no idea, I'm new to programming. But I can say for sure that it's horrible to use compared to other languages that I've used in production (Ruby, Clojure, Javascript). I would bet anything that being able to use any language/workflow of your choosing and compiling to iOS native through JS will be a better business decision than coupling yourself to XCode/Swift and whatever hacks you build to make the workflow less painful.
You seem to be lumping Xcode with Swift.
Have you tried using Objective C? The Xcode support is fine. The debugging experience is fantastic.
Have you tried using Objective C? The Xcode support is fine. The debugging experience is fantastic.
I think the debugging experience is the same as just about any other platform that I've worked on. It's not significantly better or worse (I work mostly in C++/VS/Win have recently started work on a mobile project that required me to get acquainted with Xcode).
I'm comfortable with Objective C but I can certainly see the allure of Swift. Having said that, I'll bet that it's less XCode/Swift that is preventing newcomers from iterating quickly as much as the platform itself. Rather than really learn the platform, quite a few devs seem content treating it like browser and leaning on a webview.
I'm thrilled to see where React Native takes us but something tells me I'd have a hard time getting it past the lawyers based on some of the licensing comments I've read here.
I'm comfortable with Objective C but I can certainly see the allure of Swift. Having said that, I'll bet that it's less XCode/Swift that is preventing newcomers from iterating quickly as much as the platform itself. Rather than really learn the platform, quite a few devs seem content treating it like browser and leaning on a webview.
I'm thrilled to see where React Native takes us but something tells me I'd have a hard time getting it past the lawyers based on some of the licensing comments I've read here.
You had a point with your first paragraph but fell flat with sentence one of your second paragraph.
JS->iOS is the way of the future, beacuse increasingly you can get to Javascript from any language. So for example, if your backend data system is built in Clojure you can get to Javascript via ClojureScript which is a Clojure->Javascript compiler. If you wanted to build a web application off your data model you could use your Clojure data model on the front-end, the final HTML produced is just some web rendering of that data model.
Traditionally if you wanted to build an iOS app off the data model, you would need to hire an iOS developer who knows XCode/Objective-C to build a separate application that communicates with your backend through some REST/JSON combination. But with React Native I can just take the ClojureScript components that I'm already rendering on web and give them alternative renderings that target iOS native, because it's all just Javascript/React, and build my app that way. It's much easier for the person who created the initial domain model to build native components in the exact same workflow without missing a beat. iOS native is just a rendering target for your Javascript component just like web is, and you can code it in any language that can get to Javascript.
In a sense you're just building one application, and making it work natively anywhere, instead of building multiple decoupled applications. I am literally betting my future on this being a better way to build mobile applications, I'm sure that it is. The biggest barrier to making it work is the staggered release cycles you need because of the app store approval stop gates, but hopefully that will get cleaned up in the next couple years.
Traditionally if you wanted to build an iOS app off the data model, you would need to hire an iOS developer who knows XCode/Objective-C to build a separate application that communicates with your backend through some REST/JSON combination. But with React Native I can just take the ClojureScript components that I'm already rendering on web and give them alternative renderings that target iOS native, because it's all just Javascript/React, and build my app that way. It's much easier for the person who created the initial domain model to build native components in the exact same workflow without missing a beat. iOS native is just a rendering target for your Javascript component just like web is, and you can code it in any language that can get to Javascript.
In a sense you're just building one application, and making it work natively anywhere, instead of building multiple decoupled applications. I am literally betting my future on this being a better way to build mobile applications, I'm sure that it is. The biggest barrier to making it work is the staggered release cycles you need because of the app store approval stop gates, but hopefully that will get cleaned up in the next couple years.
I don't buy it. This is the same argument I've heard from Node.js proponents.
You'd be offloading your development and debugging to a third party tool that will always be staggered behind native development.
You'd be translating your code through a shitty javascript transpiler.
You'd end up hiring javascript programmers with little to no domain knowledge to make apps that feel less than native.
You'd end up having interface with the platform anyway, but through a JS shim.
You'd be putting all your eggs in one basket on a platform known for killing off its dependents. Apple doesn't like what React Native is doing to its ecosystem? You're shit out of luck when they pull you from their market.
Hire a competent person with the relevant experience instead of trying to shoehorn javascript into every problem domain. You'll end up hiring one anyway.
You'd be offloading your development and debugging to a third party tool that will always be staggered behind native development.
You'd be translating your code through a shitty javascript transpiler.
You'd end up hiring javascript programmers with little to no domain knowledge to make apps that feel less than native.
You'd end up having interface with the platform anyway, but through a JS shim.
You'd be putting all your eggs in one basket on a platform known for killing off its dependents. Apple doesn't like what React Native is doing to its ecosystem? You're shit out of luck when they pull you from their market.
Hire a competent person with the relevant experience instead of trying to shoehorn javascript into every problem domain. You'll end up hiring one anyway.
I agree that the app release process is very poor. I learned recently that the app store review process does not necessarily include a human test. This was a very annoying discovery as it resulted in a dreaded 'release-only' critical bug.
This is so true on both android and ios tooling is a nightmare lately I switched to meteor/cordova but still ios requires an expensive Mac to build which I can't afford.
My ignorance may be showing here: can you just run the OS in a VM and compile that way?
OSX is only licensed to be run on Apple hardware.
Ah I did not know that, thank you.
Also, with react native you can push software updates over the wire without Apple even knowing.
App Store Review Guidelines 2.7 states:
> Apps that download code in any way or form will be rejected
If the platform terms ban it, it doesn't matter if it can be executed technically.
> Apps that download code in any way or form will be rejected
If the platform terms ban it, it doesn't matter if it can be executed technically.
It's allowed - there's an explicit exception for downloading code and executing it via WebKit http://info.meteor.com/blog/apple-hot-code-push-mobile
Yes.
If you build something with zero customer feedback or marketing channel in place, would you really expect it to blow up right out of the gate?
Ask yourself this question about ANY other business model?
Sure, when the app store got started, you could throw something up and maybe get lucky because the competition wasn't there. That's changed, it's become more competitive and you have to bring more to the table.
This is reflected in any market as it matures. I don't understand why people are freaking out about it. It's entirely possible to build an MVP with a few thousand dollars and a few months. Sure, failure is part of the process, but that's more of a factor due to these companies raising HUGE amounts of money on big visions before launching, failing to achieve product/market fit.
In the VC world, that's a bust and you close up shop. If you're bootstrapped, that's a learning experience and a chance to pivot.
If you build something with zero customer feedback or marketing channel in place, would you really expect it to blow up right out of the gate?
Ask yourself this question about ANY other business model?
Sure, when the app store got started, you could throw something up and maybe get lucky because the competition wasn't there. That's changed, it's become more competitive and you have to bring more to the table.
This is reflected in any market as it matures. I don't understand why people are freaking out about it. It's entirely possible to build an MVP with a few thousand dollars and a few months. Sure, failure is part of the process, but that's more of a factor due to these companies raising HUGE amounts of money on big visions before launching, failing to achieve product/market fit.
In the VC world, that's a bust and you close up shop. If you're bootstrapped, that's a learning experience and a chance to pivot.
I think it's really good that everyone is so paranoid about repeating "the bubble". Articles like these should continue coming out and tempering attitudes.
Previous discussions:
- 2012, 93 comments: https://news.ycombinator.com/item?id=4389061
- 2013, 51 comments: https://news.ycombinator.com/item?id=5915989
- 2012, 93 comments: https://news.ycombinator.com/item?id=4389061
- 2013, 51 comments: https://news.ycombinator.com/item?id=5915989
This is the gem :).
Eventually the blog will get it right.
I know that the date of this article has been outed, but if you view the source, that's another way to get the date:
meta property="article:published_time" content="2012-08-15T16:43:53+00:00
meta property="article:published_time" content="2012-08-15T16:43:53+00:00
What... on earth is this guy talking about...
"The long cycle times for developing mobile apps have led to startup failures that look more like 1999 – it’s like we’ve forgotten all the agile and rapid iteration stuff that we learned over the last 10 years."
That's not it. At all...
Has this guy written ANY code himself?
Long cycle = 6 months? Get a clue...
What he's really saying is 'Gee, I thought there was easy money to be made by just throwing it at geeks who mention 'mobile' and it turns out, that doesn't quite work. I conclude that it must be the geeks' fault. I handle other people's money so I must know what's wrong - geeks forgot 'agile' and 'rapid' and 'iterative'. Surely it is not me who is the ignoramus here. I handle other people's money, I must know what software development is about. I handle other people's money and I write nice sounding things online to have more people trust me with their money, I am an expert at sounding like I know what I'm talking about.'
"The long cycle times for developing mobile apps have led to startup failures that look more like 1999 – it’s like we’ve forgotten all the agile and rapid iteration stuff that we learned over the last 10 years."
That's not it. At all...
Has this guy written ANY code himself?
Long cycle = 6 months? Get a clue...
What he's really saying is 'Gee, I thought there was easy money to be made by just throwing it at geeks who mention 'mobile' and it turns out, that doesn't quite work. I conclude that it must be the geeks' fault. I handle other people's money so I must know what's wrong - geeks forgot 'agile' and 'rapid' and 'iterative'. Surely it is not me who is the ignoramus here. I handle other people's money, I must know what software development is about. I handle other people's money and I write nice sounding things online to have more people trust me with their money, I am an expert at sounding like I know what I'm talking about.'