[dozy]

I once worked for Pyxis Mobile (now Verivo Inc.) which touted a platform which would provide you with native iOS, Android, and BlackBerry (years ago..) apps, which would build themselves at run time based on a database/app meta data. This allowed apps to completely change themselves without a resubmission, while being in-line with Apple's guidelines, and technically be purely native. Between lazy loading and the fact that the interfaces were simple, the system worked well. Point being - I've thought a lot about and seen the result of the "avoid app store submission" value proposition.

After all these years, I find the aforementioned value proposition...not that valuable. In my experience it's fine to only be able to push iOS updates on something like a once/week cadence. Of course on Android, you can push daily if you really want to.

Ultimately, my thought is that with all of the complications and hard work required to create and maintain a mobile app, this is a tiny piece, and should play little into your decision when choosing to develope natively vs. w/ Meteor/phonegap vs. something else. Of course, the geek in me and the Android fanboy in me loves skirting Apple's "guidelines". :)

[EGreg]

Have you ever done A/B testing?

That's the real value if you want to actually measure things and improve them. Maybe doing so can even minimize spectacular bugs when you push. And how would you accomplish this A/B iteration with weekly pushes to everyone?

[ewang1]

You could code both views and show one or the other based on a server-side flag.

[EGreg]

And that is rudimentary "code push" isn't it?

[efdee]

I don't think that it is. You include both views in the submitted app and decide to show only one. There's no code push being done.