Boy is it time for another round of "Hybrid Apps, Wave of the Future!"? Disclaimer: I've been writing and shipping iOS apps since shortly after the iOS SDK exi

Boy is it time for another round of "Hybrid Apps, Wave of the Future!"? Disclaimer: I've been writing and shipping iOS apps since shortly after the iOS SDK existed, and writing and shipping Android apps for the last couple of years. My opinions may be biased. First, a couple of observations to get out of the way that may support author's thesis, but IMO not really: - A good portion of existing native apps should not be apps at all. These are apps for services that are infrequently used, and should have been websites the entire time. Note that I'm saying they shouldn't be apps at all - native or hybrid - they should simply be websites. Because of the friction of installation, shipping an app for something users will only very occasionally use, is pointless. - If your apps are strictly by-the-numbers CRUD apps without background activity, then a hybrid approach is likely the best bet. Now that that's out of the way... > "A Hybrid version of an app will never be as fast as a native version of the same app, but it doesn’t matter as long as the Hybrid version is fast enough." This assumes the lack of competitors who are willing to put in the effort to make a performant app. It should be noted that janky, slow UIs that are "good enough" were the norm before the iPhone came around and raised everyone's expectations. If you're building an app for Comcast or your local utility company - where competition is definitionally non-existent, then yes, it doesn't really matter as long as the hybrid version is fast enough. For markets with competition, this simply produces a large window for someone to eat your lunch. > "You get to utilize your existing JS, HTML, and CSS skillset to develop a single codebase that runs on both iOS and Android." This seems user-hostile. For all of Apple's warts, one of the great things they did around the iPhone is to rebalance consumer software development away from developer convenience and towards user convenience. The 90s and early 00s was defined by software that was difficult to use, engineered to be just "good enough", and largely the process was geared around developer ease rather than user satisfaction. Yes, as devs we want all kinds of shortcuts to make our lives easier - and by all means we should pursue them - but the market in many places no longer tolerates the UX compromises of certain shortcuts, and consumers have come to expect apps to respect their platform's UX standards and have a high performance bar. Case in point: Java apps also allowed devs to ship multi-platform from a single codebase, anybody here actually enjoy using those things? Practically nobody does that any more. > "Viewing changes on your device during development is nearly instantaneous." This is legitimately a great feature of web dev vs. native. There is a lot of work being done on iOS and Android to shorten the preview cycle - but it's nowhere near web-quick (and is unlikely to ever be). But again, this is a developer convenience, not a user convenience, and like all developer conveniences, it should only be pursued without harm to user experience. > "You can push updated JS, CSS, HTML, fonts, and images directly to all of your users without needing to recompile the app’s binary and getting App Store approval." This is the part I wanted to touch on most: DO NOT DO THIS. This is explicitly against App Store TOS and can/will get your app rejected or pulled without notice. You cannot ship features to the App Store without a binary update. This is also not a hypothetical - Apple has recently started ratcheting up enforcement on apps that significantly modify functionality while bypassing the review process. If you want to build a hybrid app despite my objections, by all means, but do not use code push features and especially do not use it to bypass Apple review processes. This will end poorly for you.