Cake
  • Log In
  • Sign Up
    • Discovery

      In the initial App Store land rush, success could come by simply being in a niche early. I was out in San Francisco during this period and in the echo chamber I had everybody telling me that the App Store was great for discovery. It was.

      For the first few years of the App Store, early adopters were excited about installing apps. Futher, the Android interface guidelines were…bad and web apps were slow. The Apple core fandom along with the easy monetization meant the App Store was the place to be for independent app development and you wound up with a feedback loop of the best apps showing up on iOS first where they got picked up by the early adopters. The iOS customer base proved much more willing to spend which further drew developer interest.

      After a couple years, however, the land rush was over. The niches occupied, later adopters stop installing new apps constantly, and the Tyranny of Choice rears its ugly head (i.e. people don't scroll more than a page or two). The normal power law of markets comes into play so if you aren't on a top installed/grossing app list somewhere, you aren't making money.

      The native developers, of course, managed to figure this out and blogged about it a lot. The solution, as far as I can tell, is to use some out-of-store channel to juice your downloads to get high enough on a list to get traction. I don't keep that much track of it since I'm not a native dev but it doesn't sound that fun.

      Once people discover the app, there's the install process. It's pretty simple on wifi or LTE but mobile apps tend to be orders of magnitude larger than web apps and that can be pretty painful on slower connections. In either case, you still have to make a decision to download and that's one more step in the acquisition funnel. I know the Android team announced a way to try apps without installing them to try to reduce this hurdle. I've never seen it but my device may be too old for the API.

      In the meantime, web discovery is the same it's always been. You can link directly to an app on the social networks, on the news aggregators, in advertisements. You can put the app on the landing page as a demo if you want, it's just the nature of the platform.

      I don't pretend to be an expert on this part of app development but from my (admittedly web centric) point of view this seems like the web's largest sustained advantage.

      Consistency / Productivity

      I forget where I got the idea but I believe that when comparing the effect of somethig on creative work (e.g. quality of paper for calligraphy) it's more representative to compare the median work instead of the best or worst. I think of the median app as a set of screens, most of which are list + detail. You don't see it much in apps that win design awards since there's frequently a better design for a problem but it fits a lot of information architectures and is fairly easy to implement. Toss in a top level tab navigation and you have the common language of mobile app design.

      If you're making this type of UI, native toolkits are really good. The widgets are pre-built, the examples show you exactly what to do, the IDEs are set up to support you. Further, even if you're going to build out custom parts of the UI, getting an early dogfood list + detail prototype lets you start getting feedback early in the design cycle. I sincerely believe (argument from authority!) that more design cycles are the primary driver of app quality.

      That's a powerful set of advantages. When I started going through why the initial batch of iOS apps were so much better than the web apps that had been on iOS for the previous year back in 2009, I settled on the widget advantage. The problem with building web apps is that there's an expectation for building a fully custom UI for every project. Every serious attempt I've seen at building out the widget framework, usually based on years of native desktop experience, has foundered on the shoals of custom UI on its way to market dominance. The ones that have had more success (e.g. Bootstrap) are less toolkits and more predefined styles that you can apply to the widgets you create and thus fit into this pattern. I think the main reason for the failure to develop a generalized widget set is that CSS doesn't abstract and that screws everything up but the other reason was that components didn't compose.

      Happily, Jordan Walke figured out the trick to building composable components: uniform component UI with a direct projection of UI from defined state. There's a reason the React model is winning and that's because it solves a significant fraction of the problem with UI, mostly around the diffusion of state in widgets and the difficulty testing it. The web developer tools also seem to be best in class of all the ones I've tried. After the component model, the next problem was application architecture. It looks like the Elm architecture (TEA, redux is the hacky js version) is more or less winning there. The last pieces are state synchronization across the network (graphql, json-api) and a widget set. I've seen attempts at the widget set but nothing's won so far. I know how to do the widget library but lack confidence in my ability to complete a project that large.

      So in the meantime, the native devs have figured out that developing for two platforms is bad and that the Android API is meh.

      The first major effort on this front is React Native. I last poked at it years ago and I know it evolves rapidly so I'll avoid writing too much about it other than to note I also found RN to be fine. I've been meaning to look into it more because there's the awkwardly named React Native for Web that's used in high traffic real world apps but it hasn't worked its way to the top of my research stack.

      The Dart guys took TEA and put a lot of work into re-creating native looking/feeling widgets to come up with Flutter. Good on them for disrupting themselves and salute to the Dart team for justifying their existence beyond being the pet project for AdWords. I've gone through the basic tutorials (Dart is the world's most boringly designed language and thus easy to pick up) and found it fine.

      I don't think Flutter does anything particularly special from a technical level but there are a lot of developer hours in the widget cloning so I can see it possibly getting traction if nothing special comes out of the web in the next two years or so. I could also see a lower level rendering framework done the same way using the game APIs (a la juce or sciter) but the effort in emulating native widgets in a non-terrible way is a huge barrier to entry. Maybe have a non-js bridge to react native or something.

      I don't really have a conclusion here, just that the consistency arguments seem to be undercut but the shifts towards cross-device APIs. I don't think web apps have a particular advantage here but I think the disadvantage is reduced by the shift of the average app to being less remarkable.

      For the productivity, I think web projects have improved in the last decade but I also think there's a big gain to be had for basic apps and starting design cycles if someone can come up with the once and future set of widgets. For full-custom comparisons I've found that the time frames quoted by native guys seems high to me compared to the times I'd expect a web app to take but my number of samples for that is really low.

    • Offline, API Acess

      One of the most obvious deficiencies between native platforms and browsers has been access to the hardware: location api, accelerometer, camera, microphone, etc. Being obvious, it's one of the earlier things web vendors have worked on. The track record has been somewhat spotty in terms of privacy but it's been a couple years since I've wanted to use a piece of hardware on the device and been API limited.

      The more interesting side has been the development in making web apps work offline. The initial failure of the AppCache managed to get taken by the extensible web clan and turned into the Service Worker spec. I consider SW to be the main disruptive force in client side web development and not WASM, despite the hype. The main downside to most extensible web APIs (this one included) is that they're low level and kind of need a library layer on top. I've run into a few but current efforts are pretty rudimentary or exploratory. The main delay has been mobile Safari, but the API is in preview releases so there's a clear path forward.

      The public voices on the Chrome team have been beating the drum about this stuff for a while and to my knowledge they're the main drivers behind closing API parity with some pushes from Moz on the hardware stuff. They've recently started pushing for progressive web apps (PWAs) added to the home screen to have a launch/switching like an APK app.

      Obviously native is going to be ahead on new stuff, but I think that if browsers haven't completely closed the gap there's at least a fairly straightforward path towards getting there. It has, however, been a longer road than I was expecting.

      Money

      The part I'm least qualified to talk about!

      During the app store land rush, there was a race to the bottom in terms of price. After all, if you're a solo developer it's okay to only get a buck a download as long as your app shows up in the most downloaded list. This has, unfortunately, resulted in what seems to be a permanently depressed price point for mobile apps. It looks like a lot of people (I see it in games, less sure about apps) have instead taken the in-app purchase route. In either case, having a direct connection to a pre-entered credit card gets rid of one barrier to purchase and remains a major advantage for native apps.

      On the web side, the launch of Stripe has significantly improved the developer experience of connecting to a merchant gateway. Even if you don't use Stripe directly, the competition seems to have improved the process across the board. I went through the process for Stripe at one point and found it pretty painless but it was exploratory and never intended to be released. So I don't think it counts. My other projects have either been ad supported or B2B. Not exactly a position of authority on the topic.

      I do know that the Chrome team has been (again) working on a payments API to hook into the Play store on Android but just that it exists. I haven't heard how far along they are or what's involved.

    • Is the web losing?

      So, after the (long) tour through the debate I'm down to the core question. This thread is prompted by a tweet from Alex Russell:

      Most Mozillians I speak with are happy to pretend that the web isn't losing to native, and focus on desktop (where a shrinking fraction of time is being spent).

      Alex was the main force behind the Dojo project, which was really influential early in the javascript-works phase of the web. As an example, it's the library that brought promises to the JS ecosystem. He's also behind the extensible web manifesto and generally involved in the standards side of this stuff.

      The primary justification I see for this is the total screen time on mobile vs desktop is increasing (won't bother linking) and, more directly, native vs web time is increasingly dominated by native. Oh noes!

      The part I see mentioned less often is that like 75-85% of app time is spent in the top few apps. If you look those up, they're the ones you expect: Facebook, Instagram, Youtube, Twitter, the chat app, etc. The actual top set varies but as far as I've seen people are spending time interacting with their friends and family. My theory is that the dominance of app time is driven by network effects (you want to see your grandkid's photos or the cat video) and not the implementation of the app itself.

      If you ignore the network effect driven high end of the app usage curve, the engagement difference in all the surveys I've seen looks within 2-3x and usually the uniques are a bit higher on the web side. I don't really see this as one side winning heavily. I admit that this is throwing away inconvenient data points to suit my argument but I'm neither Facebook nor Google and their apps are outliers.

      I do know that Google is very focused on the situation in China, India, and Africa. I presume it's because the wealthier markets are saturated and this represents their main opportunity for growth. Mobile is absolutely dominant in those markets and seems to be more prevalent among the younger generation here in the US. Looking forward, this does make the desktop niche, particularly for the ad driven model, but I don't see what it has to do with the app vs native debate.

      In conclusion, I don't see either side as having won. I think the web has encroached much futher into native territory than vice versa, according to my expectations a decade ago, but it's still behind, which was not according to my plans. I do remain happy with my choice but I do tend to see the world more from the Mozilla point of view.

    • I found these posts very insightful, especially on the subjects of performance and discovery. Thank you.

      Speaking as a developer with a background in both native apps (I wrote lots of Windows apps from 1997 to 2004 or so) and web apps, I strongly prefer developing web apps.

      Web apps often (and this was especially true in the early days) require blazing new territory on each project, which can be a plus or a minus, but there's nothing else that even comes close to the feeling of immediacy and the fast pace that web apps allow.

      For example, in just the few days since we launched Cake to the world, we've deployed dozens of changes, including whole new features that had only been ideas a few days or hours earlier. The speed of iteration and release that's possible with a web app is unparalleled. And not just for features — when someone encounters a bug, we can often have a fix deployed to everyone within minutes.

      That said, as a user, I sometimes prefer native apps. Partly this is because the limitations of mobile devices have meant that native apps tend to have better performance, but I think it's also because many web developers don't put as much effort as they should into making web apps work well on mobile devices. It's possible, it just takes effort and attention.

      But I've never been one of those people who thinks web apps are best or native apps are best or that one or the other has to eventually "win". I think that, as you pointed out, web apps and native apps will continue to encroach on each others' territory and borrow ideas from one another, and they may eventually become similar enough that there's little difference, but I don't think either will ever completely "win".

      In the same way that movies didn't eliminate books and TV didn't eliminate movies, I think web apps and native apps will continue to coexist for many, many years. And I think that's a good thing.

    • I've never been one of those people who thinks web apps are best or native apps are best or that one or the other has to eventually "win". I think that, as you pointed out, web apps and native apps will continue to encroach on each others' territory and borrow ideas from one another, and they may eventually become similar enough that there's little difference, but I don't think either will ever completely "win".

      When I say winning, it's mostly about what the default is for non-constrained apps. I claim that the web more or less won the desktop around a decade ago because it's really rare for me to see a new native application. I know they get written and there are lots of very fine professional apps for media creation but the only native apps I use on my laptop are the browsers themselves, the terminal, an image editor, the music player, and sometimes the text editor. That's a pretty small fraction of the whole with one-off stuff like doing my banking or taxes being relegated to web sites I go to when necessary and don't have anything installed. I think this feels natural but it's not a guarantee.

      I think the debate would be milder if we hadn't had had the IE6 dev cycle and subsequent release of Silverlight. I think that put the fear of being captured into the minds of a large chunk of our generation of web developers. I think it's the same reason the AMP project has a large set of detractors from our same group. I honestly can't tell if it's just a group at Google chasing perf (like QUIC) or if it's Google trying to capture the market. The latter sounds conspiacy theory-like when I explain it to non-developers but you have Peter Teil writing op-eds explaining (paraphrasing) the goal isn't to turn a healthy profit but rather to capture the market and collect rents. I don't see any strong threats to mobile being captured in the US the same way that, say, WeeChat in China seems to be gaining traction but I do think that having a strong platform on the web is the main bulwark against any one company achieving a monopoly on future app creation.

      I'm generally in the camp that doesn't like the Internet of Things (short for Internet of Things that shouldn't be on the Internet) but the cost of embedded processors is cheap enough and when combined with the ubiquity of the mobile general purpose computers we carry in our pockets, I think it makes sense for device manufacturers to start saving money by leaving physical controls off their device.

      In this context I think something like the Flyweb project makes sense since it theoretically gives you the ability to manipulate these things without having to go through the current hassle of installing an app. There's no inherent need for this to be web based and a vendor could come up with some sort of data format backed by pre-defined native widgets but I kind of want it to be web based so it could be used by (say) museum curators in conjunction with locator beacons to do exhibit apps, which I see as making more sense as interactive documents.