I've literally taken to replacing some tabs in the app with web views and serving light, responsive HTML5 through them.
Unless your app is a game, or you already have found product/market fit AND have a large eng team and the resources (aka $$$) at your disposal, probably makes no sense to develop native any more. Looking at Airbnb and Instagram ditching native dev too, I'm not even sure of the latter case.
If you need to poll in the background when the phones screen is locked, then you will need to write native code. Writing native code to do this isn't that hard (react native docs are good), it's just annoying that you will have duplicate business logic for Android/iOS.
Any sources for this? I would like to read up on it.
Source - I'm an engineer at Netflix.
Given the shift towards Flux and Falcore, React Native may make sense for the iOS/Android, and potentially in Windows/Ubuntu as well (speculating).
Disclaimer, I don't work there, but did go through the interview process last year, I wasn't enthusiastic about moving to California at the time.
I can verify that it's an amazing place to work :)
The table of app development costs seems very handy, except it is missing the disclaimer: your results will vary.
"Cost of redeveloping entire app natively when a cross-platform framework limitation is hit."
This is common for non-native development.
That's what I see technical debt as. A lot of people think "technical debt" is just bad decisions that accrue over time, but you can also get into debt by taking out a loan -- with interest. I got into debt when I bought my house. Your city probably used debt to build new schools. Governments use debt to fund, well, the whole country. Facebook took out debt to move faster. And then they had to pay it back with interest, just like my mortgage and those municipal bonds that funded the schools and the treasury notes that trade our foreign debt. Fortunately they paid it back by further developing react native, and they're still pushing.
I think the Facebook engineering team is good -- they simply wouldn't survive if they weren't, and they're doing fine. I don't think they fucked anything up. I think they were conscious of the loan they were taking out, and had a repayment plan in place. So in that sense they did the responsible thing, and took out a loan for the right reasons. It worked out well for them.
I'm very interested to see where react native goes. I think Microsoft will see an opportunity to push against Apple, because people are falling out of love with Macs and are starting to like the Surface. And if the Surface starts selling, the Phone would too... except that MS has an ecosystem problem. There aren't many developers targeting Windows Mobile, and there's not a ton of expertise there as compared to Android or iOS. By backing React Native, they can get developers onto Windows platforms faster, which means the ecosystem can keep pace with the market if they can keep showing quality hardware especially for power users and professionals. So we may see some MS+FB friendship in the near future.
It feels like the UI is changed quite frequently, which when you combine with the bugs and various anti-patterns (out of order content, making basically any activity appear in the "globe" notification, messenger opening another app, unable to find old posts, etc, etc..), it's a super-irritating experience at all times.
Out the 3-4 mainstream ones, I am quite familiar with
Cordova / PhoneGap
The main problem that I see, is the lack of ecosystem support for both of these. For example, you want to use latest features of a third party SDK, you find out that they only have native libraries available. Then it falls on your plate to create the JS or C# wrappers for these native libraries. This calls for a specialist who has experience in writing these wrappers. There are not that many people who have experience with this. So it also ends up being expensive.
Another problem is that the "idea" / "visionary" people don't understand the limitations of the cross platform development. They keep coming up with user experience demands which don't really fit well in the cross platform sense. When you the programmer tell them that it's very time consuming to do it in the chosen technology, they refuse to understand and argue a lot citing examples from other popular apps. Most of these popular apps are from companies who are very well funded and have access to extraordinary programming talent. They undertake creation of custom components/frameworks as part of their app development. This is really not possible for small agencies / small startups.
In the end the cross platform approach always ends up making up some compromises. If the senior management of the product understands the compromises and is wiling to live with it only then it works out. Still from time to time, there are discussions about whether "right" technology was chosen when you find a limitation of the chosen approach which makes a new "groundbreaking" feature very expensive to implement.
This could be easily solved if HTML5 apps were first class citizens in Android and iOS like they are in Chrome OS.
Relying on third party solutions like Cordova, Crosswalk, is frustrating.
Solutions like ReactNative and NativeScript are also unsatisfying and both iOS and Android should offer a similar solution (native engine + scripting behaviour) without relying on third parties. This is common practice in the video game industry and prevents 15 or more minutes of compile times.
I'm looking into Flutter/Dart from Google for building iOS/Android apps from the same codebase.
The SDK is still alpha so there are still rough edges, but I've created a POC app and have been able to run it on both platforms. I'm very pleased with the results so far.
Of course, it really depends on your needs... I'd frankly be happy if it meant apps would render fonts at a size I can read... I'm far sighted and rarely need glasses for anything at a distance, but the few feet from my face, primarily my phone is often irritating, and FB was always the worst offender at not following the accessibility settings on my phone.
Re 15 minute build times, Facebook iOS is 301MB! Makes me seriously wonder which is larger, FB iOS or facebook.com
This is like hiring undergrad and fresh graduate mathematicians to build a space shuttle. It's not a matter of competence or intelligence. It's a matter of ego and inexperience (engineering is an easily learned skill; all that matters is selecting the right data structures and algorithms from my CS [1-4]xx classes, etc.).
Also, the last time I really tracked battery usage, it was the more intrusive social apps (all native) that ate the most battery.. and the screen uses more than any app.
This is the real killer feature to me but it also seems like the sort of thing Apple will quickly
shut down if it gets popular.
Are there apps right now that
Is it really better to have to download 10s or 100s of MB of JS every time (yes, yes, caching helps) you want to use an application instead of a one-time install of a couple of GB?
Edit for clarity: I'm responding to the part of your comment about web apps "eating" the install-based model of desktop apps, specifically, not to the broader topic of mobile apps (as clearly there's a difference in the model, packaging of applications, etc. there).
No- the crappier your computing experience will become, which is already happening.
However there is significant effort being made in making these browsers better, so perhaps something will improve.
JS isn't nearly as offensive as those exaggerated numbers by comparison
Nothing more irritating then being forced to update / download content when you need to go and quickly do something in an app.
It also means they can add, change and remove features whenever they want, that isn't consumer friendly.
There is also a growing ecosystem of open source projects and companies offering services that offer and facilitate over the air updates.
I'm thinking many people at Apple are happy to encourage OTA updates and even side loading apps. The original guidelines were dictated by you-know-who and so that's what they rolled with, but are willing to look the other way now (even though this type of code push directly violates the spirit of the App Store as a closed and controlled environment)
However, about 2 months ago, the mobile team at my current workplace announced a new product built with several React Native components. They specifically mentioned that they had gotten clearance from Apple on downloading JS bundle updates outside of full app releases. I haven't personally reviewed the TOS to see if there is a change to the language, YMMV, IANAL, etc.
If you can do both for 150.000 and get something that works perfectly on both you're lucky.
Being able to target Android/iOS[/WP, relevancy aside] (and UWP in part, with a shared logic codebase), is pretty nice. I rather suspect it will get full UWP support in due course, also.
In my experience, it's fast at runtime, very easy to debug, very customisable UX, easy to code for in a pleasant, highly productive language with amazing tooling (best in VS, but Xamarin Studio on Mac or Linux isn't bad, especially compared to the competition), allows you to share often the vast majority of the codebase across platforms, has very good, but optional, Azure integrations should you want them - and free. Pretty compelling offering, I'd have thought!
The iOS/Android SDKs are already complex enough to deal with when you're writing native apps. When you introduce a third-party framework that wraps the native SDKs, you now have to worry about bugs in that framework, plus bugs in the bindings to the system SDKs, on top of bugs in the system SDKs themselves. (Of which anyone experienced in iOS/Android development knows there are already plenty.)
React is very trendy right now and I think that's why React Native is getting a lot of attention, but I think there's a good reason similar cross-platform frameworks like Xamarin and Titanium have only reached niche status, and most mobile-first apps are still developed natively.
> This means that you can push updates, features, and bug fixes instantly to your users, bypassing the labor of bundling, submitting, and having your app accepted to the App and Google play stores
... and violate the Ts&Cs of both!?!?!
Ultimately, the problem-solution should determine which platform is used including what you use for backend programming. I find that it is equally difficult to find good qualified people in React and React Native as it is with Objective C, Android Java or Swift. So it is 6 to 1/2 doz.
I'm a web developer by day (Ember / Node) and believe that the web platform will ultimately come out on top due to its inherent cross-platform support, "install-less" use, and open design. For the time being, though, browsers still lack support for many hardware APIs, which still make native apps necessary for many interesting use cases.
The use cases I'm tackling with my current app require MIDI and Bluetooth Low Energy support. There is interesting work underway to draft web standards for such APIs (there is a working draft for web MIDI that is implemented in Chrome and an unofficial web bluetooth API that can be turned on in Chrome), but general support is far off.
In my case, my app communicates with an embedded Bluetooth SoC in a product I'm developing, and I'm able to reuse C libraries I originally wrote for the embedded platform in my mobile apps. So, I'm sharing my mobile app code across and iOS and Android (huge win) and sharing some core messaging code across iOS, Android, and my embedded platform (bonus win).
My requirement was simple. I needed an app which will allow the end user to enter their zip code and it will fetch a list of our retailers within x miles radius. You highlight the store and get the address and phone number. That's it!
The first phone call turned to two, three, four...being introduced to several team members/project managers etc. I had to provid detail requirements.
They storyboard the shit out of this and came back with 30k for a native iOS app. No shit!
After back and forth they offered to do it for 15k.
It took one evening and I did it in hybrid for multiple OS.
EDIT - I kept the quote on my desk. Showed the boss the following week. He said, that's why you make the big bucks! Earn your keep.
3rd party companies are going to make more money the larger, and more complicated the project. If there's little chance of return work, then they also make more money the buggier the project.
Their incentives are not your incentives.
Now they move slow with broken things.
yeah this is true, but it's not a relevant priority to google or apple.