4 ms·

Ask HN: App shops all telling me frameworks not worthwhile; only use native code

5 points by tempestn 10y ago

I've been shopping around to outsource the initial development of iOS and Android apps for AutoTempest.com to a dedicated app development shop, since we don't have any mobile app experience in house. Haven't decided whether to go that route yet, but wanted to get an idea of the process and costs. I've been surprised to find that every shop I discuss with is adamant that straight native code (Swift for iOS and Java for Android) is the only way to go. Opinions range from, "Hybrid frameworks are useless, and will give you a noticeably inferior app," to the slightly less extreme, "You might save a bit of time using a hybrid framework initially, but you'll pay for it over time as you have difficulty adapting to changes in the platforms and adding features." Coming from a web develop background, this obviously sounds a bit backwards to me. But all of the teams I've talked to have great portfolios, and have build beautiful apps for major companies, so I have to think they have some idea what they're doing. Is it possible they all have this position just because of inertia? I could see there being significant tradeoffs with a hybrid framework like PhoneGap, but what about something like React Native that (at least, as far as I understand) allows you to use native code wherever necessary? It seems like that should save time, especially if 1) you're developing for iOS and Android, and/or 2) you already have a web app that uses React. Or do they know what they're talking about, and even RN would only be good for a quick & dirty throwaway app?

atleta 10y ago
As others have said, these companies probably have experience (and love!) with building native apps. Now if they haven't built anything serious with the latest non-native solutions, then their opinion will be just that: an opinion, but not expert advice. Also worth noting that their advice (go native!) can't be wrong technically. The native app will never be worse than the non-native one (given, of course, that the same level of effort and knowledge goes into them). If they don't do non-native apps, then they either take extra risks and efforts (which will very probably eat up any theoretical savings). I would say that you should find a company that does hybrid apps as well and ask them too. Or, instead of a company, you could look for an expert for advice and have him help you make a decision and pick a subcontractor based on your detailed requirements. Speaking about the technology: both PhoneGap and RN allows you to implement parts in native. React Native is called that, because it renders the UI using native components. (With PhoneGap you're running in webkit and thus your UI is html.) Here's my 2 cents on hybrid apps: I have build one using PhoneGap over 5(!) years ago. Well, almost 6 now. The MVP for my first startup. It was pretty simple, but looked nice, worked well on low end android smartphones (of the day!) and had everyone wondering how I was able to build all that (app, backend and a component running on a Shiva Plug) by myself. In hindsight, one of the mistakes I made was that I gave in when we got funded and agreed to have the app reimplemented in native for both platforms (ios+android). This cost us quite some money and time and it turned out that the users didn't really use our app anyway. One of the strengths of having a cross platform app is that you can do experiments with it a lot cheaper and quicker, for you don't have to implement everything twice. Especially, in your case where you have in house web devs, but no mobile devs. I have just met one of my former employees from the above mentioned startup of mine. He now works for an agency as a mobile developer. Back then he only did iOS, now he does Android as well. He showed me one of their newest apps for a big sports brand. They did that in RN. It looked pretty neat. It used OpenGL for the graphics on at least one screen (that was implemented in native). It was something that I would have said not to implement in JS, but the guy told me that it was a pretty successful project for them. The agency he works for only has 2-3 native mobile devs and a lot of web devs. I think he was the only mobile dev on this project with 6-7 web devs doing most of the code in JS. Of course, RN is fresh technology and can cause surprises. Another thing to consider, if an app is barely more than the mobile version of a website, then going 100% native might not make a lot of sense. Also, until you have enough mobile users, you might want to try something simple. Maybe even just a progressive web app.
informatimago 10y ago
First I would notice that this is a problem that has remained unsolved for 34 years, since the diffusion of PUI (GUI from PARC). At the time, we had the Mac "framework", the Atari (Gem), MS-Windows and X11 "frameworks", and already then, people tried to design meta-frameworks allowing them to write a single PUI application and deploy it on those multiple systems. Whole books were written about the, describing by the minutiae the commonalities and differences between those frameworks, and explaining how one could write a common application, or port applications from one to another. Needless to say, not much progress or success has been made since. You have things like Delphi or the JVM that can let you develop applications that can run on all those platforms, but they still always remain somehow alien to each of the platforms where they run. Yes, indeed, there are such tools to build Android and iOS applications from a single source. If your application is not demanding on the user interface (ie. if it has a simplistic user interface) and on other features of the platforms (sensors, toolkits), then basically it will do. However in practice, and this is why you get those responses from app dev shops, your application will want to use specific features on each specific platform, or will have some UI sophistication that won't be handled satisfactorily by the meta-framework, and this is when it'll start to be a lot more work trying to build the applications with them, instead of writing two native UI applications. In addition, to do it correctly with a common meta-framework, you would need a developer who knows well both target platforms, and who is capable when developping on the meta-platform, to think ahead how his code will run on both platforms! This kind of developer are more expensive than two developers each specialized on his own platform. All is not lost however, since you should modularize your software anyways, you will have components that are generic to your application, and components that are specific to the user interface. Only those later components need to be developped in two different versions, on the target platforms. The generic core components can be developped once for all, in the form of a library that will be used by the native applications. The only downside here is that these generic core components will have to be written in a common programming language, most probably C or C++, if you don't want to fight with development environment (you could try Common Lisp, wich translators such as MoCL https://wukix.com/ https://wukix.com/, or Java which has a few compilers that you could use to target iOS such as http://j2objc.org/ http://j2objc.org/, but in all those cases, batteries are NOT included). There's a caveat: iOS and Android applications are often only user interface, they're not functional programs. Without a back-end server, in general you cannot do anything with those applications. This is both a blessing and a curse: blessing since this means that now your generic core components are implemented on the server; a curse because when there's no connectivity, the user cannot do anything. But if those generic code components are implemented on the server, then you see that there remains on the handheld computers only the user interfaces, and therefore that you don't have any common code in the Android and iOS applications. Hence the conclusion and advice given: develop two independent native applications by two specialized teams. This will be the cheapest and fastest way to do it, since the two teams can work in parallel. You have in common only the specifications, and the core components on the server, the later you can develop yet in parallel by a third team.
rkho 10y ago
I primarily do web dev work and I've been diving deep into React Native recently and have worked with Ionic for a little bit. What I find with these hybrid frameworks is that they aren't perfect. I love React Native. I think it's an incredible piece of technology and the level of accessibility and empowerment it gives web developers to venture into the realm of mobile development is a great thing. But at the same time, there are so many things that React Native cannot take advantage of -- at least, not at the Facebook-developed level (remember, Facebook's RN team is going to focus in on the parts of the framework that they can get the most value out of internally). You're going to miss a lot of things that you would normally take for granted in real native iOS and Android development such as a Camera module (yes, I know!) and OpenGL. There are third party libraries that support these things, but your tradeoff here is that you are going to either become dependent on the maintainers' ability to fix bugs and introduce new features or (if your app becomes the biggest consumer of those libraries) you will become the lead maintainer. RN is still great for letting web developers add components to an existing Swift/Obj-C/Java codebase and I really enjoy using it. However, I think the maintenance and dependency costs of building a larger-scale RN-first app might not be the best idea Regarding Ionic/Phonegap/Other "Write once, run anywhere" frameworks: I feel this is a large UX tradeoff and would never make it. Things don't feel smooth when emulated. I would never use one of these types of frameworks for production purposes.
- tempestn 10y ago
  Thank you, this is exactly the kind of insight I was hoping for. My understanding is that RN allows you to fall back to native code wherever necessary. Is that not as easy in practice as in theory? It just seems like at worst it would allow you to share many parts of your application between iOS and Android, as well as possibly your web app, and then anything else could be built natively as necessary. As someone with no experience using this tech, that seems like it would simplify and save time, both in initial development and future revisions, but avoiding duplication between code bases. I can't help wondering if these teams tried older hybrid app frameworks like PhoneGap, found them lacking, and have written off RN as being basically the same thing, while it's actually considerably more powerful. It's also possible that adding that layer adds more complexity than I'm accounting for, and really isn't worth it for the duplication saved.
MrQuincle 10y ago
We're using React Native as well, but we decided to have parts of our app in Java/Swift: + Third parties should be integrating part of our core technology in their app. I can't force them to use a framework. + We're using Bluetooth Low Energy and need to be as close to that radio as possible. + The implementation of BLE differs too much from iOS to Android to make one library a good idea. Apart from that if I would run an app shop, I would write dedicated for each platform. + More hours. + More experienced personnel. + More stable than frameworks.
- tempestn 10y ago
  As someone buying from an app shop, your second and third points would be a plus for us as well, whereas the first would obviously be a minus. Having some of the app built in a framework would probably be easier for a team of web developers to take over too, although that's not a given, since it would also add complexity. It may be moot though if there are no shops out there using RN anyway!
brudgers 10y ago
Consider the economics of the companies who build web apps. 1. They have a process for producing quality work. 2. Changing that process entails learning a new process and the risk of producing work of lower quality. 3. The value the firms provide is in the quality of the apps. It seems that your argument is that using a framework should reduce the effort a firm expends on producing an app and there is an implicit assumption that that reduction in effort should be manifested as a lower cost to your company rather than higher profits for the firm or higher quality in the app. That may indicate that your company is not a good fit for the services of the firms you have talked. Nothing wrong with that, it's just market segmentation. Might even be a good thing since it avoids misaligned business interests. I mean if your company is a profitable ongoing concern without an app, then a bells and whistles app probably isn't critcal to success and a simple wrapper on a web app might be a reasonable first pass at implementing 'mobile app as a feature' because it is the simplest thing that might work. It doesn't have to be rolled out multi-platform. It doesn't have to be rolled out to everyone right away. It does not have to be all grown up to be shown to committed users for feedback. Later on when there's a good 0.87, it might make sense to hire a consultant for the 1.0. Good luck.
- tempestn 10y ago
  > Nothing wrong with that, it's just market segmentation. Might even be a good thing since it avoids misaligned business interests. I mean if your company is a profitable ongoing concern without an app, then a bells and whistles app probably isn't critcal to success and a simple wrapper on a web app might be a reasonable first pass at implementing 'mobile app as a feature' because it is the simplest thing that might work. Yes, these are the lines we're thinking along currently. I just wanted some feedback to make sure I'm not missing something about the hybrid option, that perhaps it truly is far worse that I had come to understand. But from the responses I've received here and elsewhere, and my own research, it really does seem like a logical approach, at the very least for an MVP.

5 points by tempestn 10y ago

atleta 10y ago

As others have said, these companies probably have experience (and love!) with building native apps. Now if they haven't built anything serious with the latest non-native solutions, then their opinion will be just that: an opinion, but not expert advice. Also worth noting that their advice (go native!) can't be wrong technically. The native app will never be worse than the non-native one (given, of course, that the same level of effort and knowledge goes into them). If they don't do non-native apps, then they either take extra risks and efforts (which will very probably eat up any theoretical savings). I would say that you should find a company that does hybrid apps as well and ask them too. Or, instead of a company, you could look for an expert for advice and have him help you make a decision and pick a subcontractor based on your detailed requirements. Speaking about the technology: both PhoneGap and RN allows you to implement parts in native. React Native is called that, because it renders the UI using native components. (With PhoneGap you're running in webkit and thus your UI is html.) Here's my 2 cents on hybrid apps: I have build one using PhoneGap over 5(!) years ago. Well, almost 6 now. The MVP for my first startup. It was pretty simple, but looked nice, worked well on low end android smartphones (of the day!) and had everyone wondering how I was able to build all that (app, backend and a component running on a Shiva Plug) by myself. In hindsight, one of the mistakes I made was that I gave in when we got funded and agreed to have the app reimplemented in native for both platforms (ios+android). This cost us quite some money and time and it turned out that the users didn't really use our app anyway. One of the strengths of having a cross platform app is that you can do experiments with it a lot cheaper and quicker, for you don't have to implement everything twice. Especially, in your case where you have in house web devs, but no mobile devs. I have just met one of my former employees from the above mentioned startup of mine. He now works for an agency as a mobile developer. Back then he only did iOS, now he does Android as well. He showed me one of their newest apps for a big sports brand. They did that in RN. It looked pretty neat. It used OpenGL for the graphics on at least one screen (that was implemented in native). It was something that I would have said not to implement in JS, but the guy told me that it was a pretty successful project for them. The agency he works for only has 2-3 native mobile devs and a lot of web devs. I think he was the only mobile dev on this project with 6-7 web devs doing most of the code in JS. Of course, RN is fresh technology and can cause surprises. Another thing to consider, if an app is barely more than the mobile version of a website, then going 100% native might not make a lot of sense. Also, until you have enough mobile users, you might want to try something simple. Maybe even just a progressive web app.

informatimago 10y ago

First I would notice that this is a problem that has remained unsolved for 34 years, since the diffusion of PUI (GUI from PARC). At the time, we had the Mac "framework", the Atari (Gem), MS-Windows and X11 "frameworks", and already then, people tried to design meta-frameworks allowing them to write a single PUI application and deploy it on those multiple systems. Whole books were written about the, describing by the minutiae the commonalities and differences between those frameworks, and explaining how one could write a common application, or port applications from one to another. Needless to say, not much progress or success has been made since. You have things like Delphi or the JVM that can let you develop applications that can run on all those platforms, but they still always remain somehow alien to each of the platforms where they run. Yes, indeed, there are such tools to build Android and iOS applications from a single source. If your application is not demanding on the user interface (ie. if it has a simplistic user interface) and on other features of the platforms (sensors, toolkits), then basically it will do. However in practice, and this is why you get those responses from app dev shops, your application will want to use specific features on each specific platform, or will have some UI sophistication that won't be handled satisfactorily by the meta-framework, and this is when it'll start to be a lot more work trying to build the applications with them, instead of writing two native UI applications. In addition, to do it correctly with a common meta-framework, you would need a developer who knows well both target platforms, and who is capable when developping on the meta-platform, to think ahead how his code will run on both platforms! This kind of developer are more expensive than two developers each specialized on his own platform. All is not lost however, since you should modularize your software anyways, you will have components that are generic to your application, and components that are specific to the user interface. Only those later components need to be developped in two different versions, on the target platforms. The generic core components can be developped once for all, in the form of a library that will be used by the native applications. The only downside here is that these generic core components will have to be written in a common programming language, most probably C or C++, if you don't want to fight with development environment (you could try Common Lisp, wich translators such as MoCL https://wukix.com/ https://wukix.com/, or Java which has a few compilers that you could use to target iOS such as http://j2objc.org/ http://j2objc.org/, but in all those cases, batteries are NOT included). There's a caveat: iOS and Android applications are often only user interface, they're not functional programs. Without a back-end server, in general you cannot do anything with those applications. This is both a blessing and a curse: blessing since this means that now your generic core components are implemented on the server; a curse because when there's no connectivity, the user cannot do anything. But if those generic code components are implemented on the server, then you see that there remains on the handheld computers only the user interfaces, and therefore that you don't have any common code in the Android and iOS applications. Hence the conclusion and advice given: develop two independent native applications by two specialized teams. This will be the cheapest and fastest way to do it, since the two teams can work in parallel. You have in common only the specifications, and the core components on the server, the later you can develop yet in parallel by a third team.

rkho 10y ago

I primarily do web dev work and I've been diving deep into React Native recently and have worked with Ionic for a little bit. What I find with these hybrid frameworks is that they aren't perfect. I love React Native. I think it's an incredible piece of technology and the level of accessibility and empowerment it gives web developers to venture into the realm of mobile development is a great thing. But at the same time, there are so many things that React Native cannot take advantage of -- at least, not at the Facebook-developed level (remember, Facebook's RN team is going to focus in on the parts of the framework that they can get the most value out of internally). You're going to miss a lot of things that you would normally take for granted in real native iOS and Android development such as a Camera module (yes, I know!) and OpenGL. There are third party libraries that support these things, but your tradeoff here is that you are going to either become dependent on the maintainers' ability to fix bugs and introduce new features or (if your app becomes the biggest consumer of those libraries) you will become the lead maintainer. RN is still great for letting web developers add components to an existing Swift/Obj-C/Java codebase and I really enjoy using it. However, I think the maintenance and dependency costs of building a larger-scale RN-first app might not be the best idea Regarding Ionic/Phonegap/Other "Write once, run anywhere" frameworks: I feel this is a large UX tradeoff and would never make it. Things don't feel smooth when emulated. I would never use one of these types of frameworks for production purposes.

tempestn 10y ago
Thank you, this is exactly the kind of insight I was hoping for. My understanding is that RN allows you to fall back to native code wherever necessary. Is that not as easy in practice as in theory? It just seems like at worst it would allow you to share many parts of your application between iOS and Android, as well as possibly your web app, and then anything else could be built natively as necessary. As someone with no experience using this tech, that seems like it would simplify and save time, both in initial development and future revisions, but avoiding duplication between code bases. I can't help wondering if these teams tried older hybrid app frameworks like PhoneGap, found them lacking, and have written off RN as being basically the same thing, while it's actually considerably more powerful. It's also possible that adding that layer adds more complexity than I'm accounting for, and really isn't worth it for the duplication saved.

MrQuincle 10y ago

We're using React Native as well, but we decided to have parts of our app in Java/Swift: + Third parties should be integrating part of our core technology in their app. I can't force them to use a framework. + We're using Bluetooth Low Energy and need to be as close to that radio as possible. + The implementation of BLE differs too much from iOS to Android to make one library a good idea. Apart from that if I would run an app shop, I would write dedicated for each platform. + More hours. + More experienced personnel. + More stable than frameworks.

tempestn 10y ago
As someone buying from an app shop, your second and third points would be a plus for us as well, whereas the first would obviously be a minus. Having some of the app built in a framework would probably be easier for a team of web developers to take over too, although that's not a given, since it would also add complexity. It may be moot though if there are no shops out there using RN anyway!

brudgers 10y ago

Consider the economics of the companies who build web apps. 1. They have a process for producing quality work. 2. Changing that process entails learning a new process and the risk of producing work of lower quality. 3. The value the firms provide is in the quality of the apps. It seems that your argument is that using a framework should reduce the effort a firm expends on producing an app and there is an implicit assumption that that reduction in effort should be manifested as a lower cost to your company rather than higher profits for the firm or higher quality in the app. That may indicate that your company is not a good fit for the services of the firms you have talked. Nothing wrong with that, it's just market segmentation. Might even be a good thing since it avoids misaligned business interests. I mean if your company is a profitable ongoing concern without an app, then a bells and whistles app probably isn't critcal to success and a simple wrapper on a web app might be a reasonable first pass at implementing 'mobile app as a feature' because it is the simplest thing that might work. It doesn't have to be rolled out multi-platform. It doesn't have to be rolled out to everyone right away. It does not have to be all grown up to be shown to committed users for feedback. Later on when there's a good 0.87, it might make sense to hire a consultant for the 1.0. Good luck.

tempestn 10y ago
> Nothing wrong with that, it's just market segmentation. Might even be a good thing since it avoids misaligned business interests. I mean if your company is a profitable ongoing concern without an app, then a bells and whistles app probably isn't critcal to success and a simple wrapper on a web app might be a reasonable first pass at implementing 'mobile app as a feature' because it is the simplest thing that might work. Yes, these are the lines we're thinking along currently. I just wanted some feedback to make sure I'm not missing something about the hybrid option, that perhaps it truly is far worse that I had come to understand. But from the responses I've received here and elsewhere, and my own research, it really does seem like a logical approach, at the very least for an MVP.