It seems that the only real error made by Wheat Belly's author was bending the study by claiming its subjects were all obese with celiac disease. Apart from this, the comments contains many anecdotal responses from people who have dropped not only gluten, but all grain from their diet and had positive results. Moreover, take into account the blog's author who has published three books circulating around gluten-free foods -- something that Wheat Belly advises the reader to jettison altogether.
One of my apps went into "In Review" status at midnight (19 hours ago) and still hasn't been rejected or approved. The rejection or approval has always happened in less than 12 hours for me, so it seems like Apple might be holding all approvals until they've resolved this issue. At least, I hope that's the case... I really feel for the developers who got a slew of one-star reviews because of this.
It is worth emailing them if it takes longer than a few days. There is a process where after a couple of days, it should go into extended review, and they will email you.
Jamie, what experience or research backs your claim that mobile development is an order of magnitude slower than web development?
I've been coding iOS apps for the past 6 months now (after coding web apps for years before that). If anything, I think iOS development is easier and faster than web development.
In every company I know where there is a capable web programmer and a capable iOS programmer adding the same features to their apps (supported by a shared backend), the web programmer is an order of magnitude faster. There's no peer reviewed studies on this subject but my anecdotal evidence (from advising dozens of startups through YC) is all on one side.
If you're trying to duplicate a document-centric interface on iOS (without using UIWebView), you are in for a lot of work. Similarly, if you are trying to duplicate an application-centric interface in the web browser, you are in for a lot of work.
There is overlap, of course. If your solution is document-centric you can simply use UIWebView on iOS. If your solution is application-centric, there are a number of Javascript frameworks that look a lot like UIKit in design. This should reduce the difference as the tools end up being similar, no matter what the target. Cappuccino even lets you use much of the Apple toolchain, including Interface Builder, while targeting the browser.
If each platform gets its own independent solution, it is going to largely depend on the complexity handed down by the designers. If the web version comes with less design complexity then it will naturally be easier to implement.
An order of magnitude? Do you really mean that you've seen iOS programmers spend 10x as long on something (e.g. 10 months vs. 1 month)?
Let's imagine a simple, specific example: you want to add a button that sends a message to the shared backend and displays an alert upon success. Let's walk through the code.
In your web app, you could add an HTML button, style it with CSS, and then use jQuery to send a request and define your success handler. Probably not more than 10 lines and a few minutes (depending on much time you spend with the CSS).
In your iOS app, you could add a button with Interface Builder, link it to a method on the relevant view controller that sends an NSUrlRequest, then add a delegate method that displays a UIAlertView when the response returns successfully. Again, not more than 10 lines. And no CSS, thank god. :-)
Where is the extra overhead that you're talking about coming from?
Perhaps a binary or ternary order of magnitude, rather than a decimal one. 10x is probably an exaggeration I would say typically it's more like 2-4x.
As I'm not an expert iOS programmer, I'm not exactly sure where the overhead comes from. Given the bugs that are usually present in iOS apps, the tricky bits appear to be:
- Handling screen reorientation
- Making scrolling smooth (it's easy to load either to lazily or too greedily)
- Making it feel "snappy"
- Not segfaulting when you have an error
The web executes on hardware far faster than mobile does so you have a lot more leeway to be sloppy. Ditto for the fact that web apps can't segfault, and it's hard to actually crash a browser.
Another really important point: Doing things on mobile is easy, almost as easy as the web. Doing things WELL on mobile is much harder comparatively because the platform is lower level and less powerful.
Even if that's true, you are developing for one platform so the comparison is a bit disingenuous. Mobile development is made slower because of fragmentation, not the tools. Unless you've magically found a way to port your apps over to Android and Windows Mobile..
Windows Mobile is a bit player still, doesn't matter for startups (or non-startups).
That leaves you with Android and iOS. Most startups can start with iOS and add Android later -- there just aren't the sales numbers to prioritize Android development.
So we're back down to one platform, with native development providing definitively better results with less time.
Supporting differing platforms is not ideal, but somehow we built the entire PC industry on top of this concept, and it worked out. Maybe we should be looking at ways to bring ObjC code bases over to Android, or something that would let us re-use non-UI code.
I've been doing iOS for a year now and it's just painfully slow for anything involving a database or doing a lot of web service traffic, which seems to be most apps these days.
I'm actually looking into Monotouch now because C# is just so much easier for anything beyond snapping components together snd because every client wants an Android port now.
To be fair, it also favors higher quality incumbents over the dozens of knockoff me-too apps like Grumpy Avians, Monsters Eat My Apartments, and Temple Race+. Or worse yet, the "strategy guide" apps for games that cost more than the original game.
You can still add up to 100 characters of keywords when you submit a new binary, but because of the 100 character limit many people would also place keywords in the title. Going forward, you'll have to ensure that the keywords for a given search phrase are either in your title or in your keywords.
I completely agree, and I rant about this issue on a regular basis to anyone who will listen. Basic search relevance is an incredibly important feature (seems obvious, right?) that Apple is failing to provide. And the App Store has been open for four years! Perhaps it's the weight of the iTunes Music Store legacy code that I presume the App Store leans on which prevents progress? As it stands, the App Store today is worse than the web before Google.
Great post. Another important change: Apple used to give a lot of weight to titles that exactly matched the search phrase. If you wanted to rank highly for a certain search term, e.g. "flashlight", you could change your title to "flashlight" or "flashlight." or "flashlight+" to show up at the top of results. This trick no longer works... one of our apps went from result #3 to result #37 for the search that matches its title.
Personally, though, I love sudden upheavals like this. If you're paying attention and move fast, it gives you an edge against competitors that have become fat and happy.
> Apple used to give a lot of weight to titles that exactly matched the search phrase.
This is something I use quite often, purely as a consumer. I read a blog, or a comment on HN, reddit, et al and go looking for a specific app. Not being able to find a specific app when you know it's name is not a solution to stuffing, or whatever this problem is called.
Which paradoxically, seems to be an advantage, because it puts people in a feedback loop where they stay on the site, and every new search provides a tiny bit of reinforcement that builds the habit.
Failing to find what you're looking for because of a frustrating UI is not positive reinforcement. People stay on the site because it is the largest marketplace and they have no alternatives.
That's weird, I've never had any trouble finding what I was looking for on Craigslist. There definitely are ways that they could improve the search interface, but the current implementation works fine for me, and given their user base it works well enough for a lot of people.
Live from the scene: my partner just found that she wasn't able to log in to her Gmail account because her password was suddenly invalid. Luckily she was able to reset it quickly and regain control of the account. When she checked the recent activity, though, it showed that all logins in the past 12 hours came from her IP.
I made a mobile web app about six months ago, and this is what I heard over and over again from users: "Can you please please please make it a native app?"
Just to get our feet wet, my partner and I proceeded to write two simple iPhone apps. The first did 10x better than our mobile web app (with much less effort), and the second did 100x better. That was enough to convince us, and now we've shelved mobile web development in favor of iOS development.
That's just a personal anecdote, of course. I can't speak for the guys (or gals) behind Coder's Coffee. Overall, though, I think this is responsible for a lot of the interest we're seeing in iOS development.
It also helps that Apple has done a great job with XCode and the iOS SDK. Developing for iOS is really a pleasure.
You missed my point, ironically by perpetuating the obsession around mobile.
I meant why can't it just be a regular desktop webapp. E.g. not require a phone to access.
I don't really see myself sitting in a coffee shop thinking "I want to chat with a business guy right now", and pulling out my phone to see if any are sitting within 10 feet of me.
Granted, the app being mobile (and geo!) is probably 10x more likely to get VC investment right now; I'm just saying that, personally, I would be planning stuff like this more deliberately while sitting at my desktop/laptop than while killing time on the subway.
http://noglutennoproblem.blogspot.com/2012/03/wheat-belly-bu...
It sounds like the book often misrepresents the research that it cites.