| > "This process naturally leaks memory unless you're very, very careful." Yes, and you can do this natively without ever leaking memory. You can refresh/delete/create new UI elements day in day out indefinitely without crashing once. Having to tiptoe around memory leaks (that you don't even control since you don't control the runtime) for complex UIs makes a platform pretty darned unattractive. > "Mostly they just need to do is display profile text and a few images inline. A mobile browser can display text and images perfectly fine" LinkedIn is also a communication platform that also needs user engagement to survive. A mobile browser does not support push notifications, nor does it allow people to quickly bounce in, reply to a message, and bounce out (not without waiting for the entirety of the UI to load via browser). There is an overabundance of apps that really should be websites - but LinkedIn is not one of them. One of the chief problems with the mobile web is that you must load the UI every time, and there is a baseline performance impact (both network and client-side) regardless of how simple and optimized you make your app. You can launch a native app, do something, and be on your way before your browser can finish loading the UI, even assuming much of the UI is already cached (which for storage-constrained mobiles, is far from a safe assumption). You can optimize a web app by a pretty wide margin, but the baseline means that there are a class of interactions that just aren't realistic. > "Was the old app ever released? Did anyone have a chance to use it?" Yes, and it was remarkably well done. At the time the canonical hybrid app was Facebook, which was crashy, slow, and awful in every single way. LinkedIn's app was at the time remarkably stable and not even awfully apparent that it was web-based. |