9 ms·

Question for everybody doing some sort of cross platform mobile dev. How common is it to have NO experience with a platform's native libraries? In other words

Question for everybody doing some sort of cross platform mobile dev. How common is it to have NO experience with a platform's native libraries? In other words you didn't go from ObjC or Java to React Native/Cordova/Xamarin to try and re-use code but because you know JS or C# and weren't concerned about learning the native platform. For any that started out with no native platform knowledge did you start to dip into it as you got more experience with the cross platform tool and started bumping up against any potential limitations? I've been flirting with Swift when I have some (rare) downtime, to get a foundation, but maybe that's not even necessary anymore given the effort companies like Facebook/Xamarin/Telerik* are putting into abstracting away the native platforms. [*] I intentionally left Cordova off that list as "native" native and "phonegap" native are two different things.

nabaraz 11y ago
I would love to see some discussion around this as well. I have been playing with Apache Corodova and Windows 10 SDK lately and they look very promising. Being a web developer, I found them to be easy to get started. Are there complex apps built using phonegap/swift/cordova? What are the limitations? I know Facebook tried with a 'web app' approach and reverted back to native solution. But that was years ago.
- o_____________o 11y ago
  Using Cordova, you will always be behind any and all Mobile Safari WebKit et al bugs. This not a big deal when pushing layout around a webpage, but it can be crippling for app development as the app grows in complexity and you crave native-quality interactions. Mobile Safari's Webkit implementation has a staggering list of severe bugs. Developing under it can become a nightmare of hacks and backpedaling. Been working on Cordova nearly full time for two years now. So much wasted time. React Native is a big deal, and is very different.
  - cbsmith 11y ago
    More accurately: with Cordova, you will always be behind on iOS.
    - jbigelow76 11y ago
      I don't know about React Native, but Telerik's open source project NativeScript promises to always have 0 day support of all native platform features since it's reflecting over the native platform's libraries to expose to its own API. React Native and NativeScript seem to have all the upside of Cordova (transference of web dev skills to native platforms) with none of the downsides (lag in new OS feature implementation, webview wrapped apps), I wonder if Cordova's days of relevance are numbered.
    - lewisl9029 11y ago
      Speaking as a web developer, this is sad, but true. However, what's even sadder to me is the fact this continues to be true despite the fact that, believe it or not, the web has been the platform where most of the innovation in UI development paradigms has been taking place in the past few years. And I don't just mean in terms of the sheer number of new things coming out. The web community pioneered UI development paradigms involving functional programming techniques and immutable data, and have brought its benefits to other platforms (through projects like React Native). I personally would never want to go back to the old way of building UIs. And I suspect I'll feel the same way about client-centric data fetching when I get to try out Relay/GraphQL, Falcor, Om Next, etc in production. I really want Firefox OS to be successful for this exact reason. I don't want to have to make compromises between the best experience for my users and the best experience for myself as a developer. With a platform that makes web the native UI technology, we shouldn't have to make this compromise in theory, but Firefox OS's execution thus far has left much to be desired.
      - pjmlp 11y ago
        I don't believe it. As someone with lots of native UI experience, that has to occasionally support web projects, the web is just plain clunky and playing catch up with the RAD tooling we enjoy since the mid-90 on native platforms.
  - deleted 11y ago
    [deleted]
  - GrinningFool 11y ago
    > This not a big deal when pushing layout around a webpage, > but it can be crippling for app development as the app > grows in complexity and you crave native-quality > interactions Even on the fastest phones, web-based (including wrapped web components) simply don't offer the native experience. They come close, but there's always a slight but perceptible performance difference; and often a visual difference depending on what you're using. I realize people really like the theoretical write-once behavior that you get for simple apps when using a javascript platform, but I've been waiting for years for web-based interactions to provide native quality - and I begin to suspect we'll never get there. If you want native-quality interactions, the only solution is a native application and not common tooling via a javascript layer that runs atop the already not-as-performant-for-UI browser level. This makes your life harder as a developer, but gives your users the best possible experience for their platform. Alternatively, if you're willing to give your users a good-but-less-than-native-quality experience, that's the niche filled by those tools.
    - windsurfer 11y ago
      > Even on the fastest phones, web-based (including wrapped web components) simply don't offer the native experience. They come close, but there's always a slight but perceptible performance difference Honestly I used to believe this, but not after the release of the iPhone 5 and 6. Though there is no perceptible difference, it takes a lot of work to mimic the UI in terms of animations, opacity, and response actions, so most apps just use the default web technology which include things like a built-in 300ms delay, no response to clicking a link, etc.
      - SomeCallMeTim 11y ago
        > it takes a lot of work to mimic the UI in terms of animations, opacity, and response actions, Which is already done for you in Ionic -- including disabling the 300ms delay.
      - kbutler 11y ago
        I'd like to believe that, but can you cite some web-app or webview-based example applications?
- matthewrhoden1 11y ago
  Sworkit was supposed to be an example of a complex app for ionic, not sure what else is out there. I've used that app and can say it seems pretty solid (no crashing, locking up my phone, etc.) http://blog.ionic.io/built-with-ionic-sworkit/ http://blog.ionic.io/built-with-ionic-sworkit/ I did a pet project using the vibration feature and it worked pretty well, but haven't tried on an iphone. I can't speak for pushing the limits of the hardware though.
cbsmith 11y ago
Game developers do it all the time with C++ using things like Marmalade.
msoad 11y ago
To my experience if all your apps do is showing tables of information and forms to put the information back in (classic WinForms app) any of the cross-platform stuff will work for you. Obviously React is rendering in native and I would prefer it. But if your app is more advanced like a drawing app you should not use these cross platform stuff.
- misiti3780 11y ago
  or for iOS, any type of advanced animations. i like the idea of these platforms but if you building a mobile only app (like instagram when it launched) i cant imagine starting off with cross-platform tech stacks
lewisl9029 11y ago
Not sure how common it is, but I've worked on a few Cordova apps and have no native experience whatsoever. I have ran into some roadblocks that required stepping into native development to fix up issues with Cordova Plugins (specifically for background operation), but I suspect that won't be necessary for a large majority of apps out there. Personally, I find the Hosted Web App spec a very promising alternative to Cordova for app development with web technologies. You simply use the open web APIs (notifications, geolocation, camera, etc) for features that would normally require messing with plugins in Cordova, and they would just work. https://developer.mozilla.org/en-US/Marketplace/Options/Hosted_apps https://developer.mozilla.org/en-US/Marketplace/Options/Host... It's such a shame that the biggest players (Android and iOS) probably have no plans to support it natively since it would greatly reduce developer lock-in. In the meantime, the ManifoldJS project can provide Cordova-based polyfills for your Hosted Web App, but then you'd have to resort to messing with plugins all over again for the only two mobile platforms that really matter... http://manifoldjs.com/ http://manifoldjs.com/
declan 11y ago
If you're going cross platform, the key is to know in detail the limitations of this approach, even if it takes longer to make that initial decision about what path to take. Different cross-platform tools have different approaches, but as a concrete example take Corona SDK. You need no native platform knowledge and your app runs inside the Corona runtime, which makes some difficult things easy but some easy things -- third-party SDK integration, install source tracking -- difficult. And if the creator of the cross-platform environment has chosen not to support certain things, you're out of luck (and you're probably always going to be lagging even for things that are supported). On the other hand, you have only a single codebase to maintain and single-click builds for a lot of platforms. As for Cordova, we spent some time testing if the performance was sufficient when building an early version of Recent News (https://recent.io https://recent.io -- v1.0 just released three days ago!). We concluded it was not. Boot times were slow, the UI felt very non-native, and overall performance didn't meet our requirements. Now that was a while ago and Cordova may have improved, and hardware performance certainly has improved, so maybe it's a better option today.
- jbigelow76 11y ago
  the key is to know in detail the limitations of this approach There's the rub. If you don't know anything about the native platform then you "don't know what you don't know". The NativeScript demo shows how to pull in a native ObjC function (a string related method I think), but if you start with no background in the native libraries how would you even know when you could be leveraging a native library function instead of trying to recreate a sub-optimal approximation in JS. But if you have the foundation and know the native platform, why jump ship to JS at all? And then I'm right back where I started :)
  - vickychijwani 11y ago
    > But if you have the foundation and know the native platform, why jump ship to JS at all? I'm a (native) Android and JS developer. The primary reason I'm excited about React Native is that I don't have to go through the tedious compile-install cycle for every little UI change. React Native will make prototyping/iterating on Android as easy as it is on the web. However my reasoning assumes that there will be almost no friction in terms of creating complex views in React Native. I'm curious to see if that pans out.
lhorie 11y ago
I got into native development with no experience in the iOS/Android APIs, coming from a web dev background. I did know Java and C from working on side projects, and read up on Objective-C before, though. At my previous company, all the developers doing native work had no prior experience w/ mobile development (i.e. they primarily had backend C# experience) I dabbled w/ Cordova and friends before, and did some work to wrap webapps in thin native shells earlier on, but there was always a very strict separation between the "sandboxed" webapp and the native code, if any. Webapps can and do work just fine for CRUD applications, but right now, I'm of the opinion that if you want to really leverage the hardware APIs or the native ecosystem, you're better off learning the native platform, because you get no syntax mismatch friction on Stack Overflow etc, compared to Xamarin / React Native / Ambly / whatever Also, this opinion might be unpopular among the js devs who like lightweight text editors (disclaimer: I'm one), but the heavy IDEs for Java/ObjC/Swift are actually immensely useful once you get familiar w/ their features. The static typing provided by those languages helps a lot in large refactors, in API discoverability/autocompletion and in reasoning about the codebase in general.
- tmail21 11y ago
  We are a startup that went the React Native route. We initially started with Ionic, but then switched to React Native. You can read about our experiences here: https://tmail21.com/blog/why-our-startup-chose-react-native-and-what-we-learned/ https://tmail21.com/blog/why-our-startup-chose-react-native-...
aikah 11y ago
You'll be limited by the widgets/apis whatever abstraction gives you. Sometimes it is enough, often it is not.
pakled_engineer 11y ago
I have zero native development experience on any mobile platform and write apps abstracted away in Scheme https://github.com/part-cw/lambdanative/wiki/Getting-Started https://github.com/part-cw/lambdanative/wiki/Getting-Started After you write/run a lot of tests to make sure the app does what it's supposed to (there's paid services for this kind of testing too) http://googletesting.blogspot.ca/2013/08/how-google-team-tests-mobile-apps.html http://googletesting.blogspot.ca/2013/08/how-google-team-tes... This React abstraction can use Chrome Developer Tools for debugging though, that's pretty awesome.
johncolanduoni 11y ago
If you stick with the tools which actually don't abstract the native platforms (e.g. RoboVM and Xamarin), I think you will learn native development quite easily. I've taken this approach, and I've had no trouble using documentation/StackOverflow to write equivalent code in Java/C#. Since pretty much all the APIs in these tools are 1-1 with the native APIs, I've also had no trouble going in the reverse direction and writing Swift/Objective-C/Java. You will still need to learn the languages, but you won't need to re-learn the APIs (which is the time consuming part). Personally, I see little to no disadvantage with using these particular types of tools, especially if it means you can use languages like Scala, C#, and F# instead of Objective-C and Java.
- tluyben2 11y ago
  I started serious app dev with Xamarin before I ever touched ObjC. After having implemented a ton of apps I am able to move between Xamarin/RoboVM/ObjC/Swift/Java quite easily. I dabbled with Cordova and Titanium before that a bit but that was not a good experience for me.

nabaraz 11y ago

I would love to see some discussion around this as well. I have been playing with Apache Corodova and Windows 10 SDK lately and they look very promising. Being a web developer, I found them to be easy to get started. Are there complex apps built using phonegap/swift/cordova? What are the limitations? I know Facebook tried with a 'web app' approach and reverted back to native solution. But that was years ago.

o_____________o 11y ago
Using Cordova, you will always be behind any and all Mobile Safari WebKit et al bugs. This not a big deal when pushing layout around a webpage, but it can be crippling for app development as the app grows in complexity and you crave native-quality interactions. Mobile Safari's Webkit implementation has a staggering list of severe bugs. Developing under it can become a nightmare of hacks and backpedaling. Been working on Cordova nearly full time for two years now. So much wasted time. React Native is a big deal, and is very different.
- cbsmith 11y ago
  More accurately: with Cordova, you will always be behind on iOS.
  - jbigelow76 11y ago
    I don't know about React Native, but Telerik's open source project NativeScript promises to always have 0 day support of all native platform features since it's reflecting over the native platform's libraries to expose to its own API. React Native and NativeScript seem to have all the upside of Cordova (transference of web dev skills to native platforms) with none of the downsides (lag in new OS feature implementation, webview wrapped apps), I wonder if Cordova's days of relevance are numbered.
  - lewisl9029 11y ago
    Speaking as a web developer, this is sad, but true. However, what's even sadder to me is the fact this continues to be true despite the fact that, believe it or not, the web has been the platform where most of the innovation in UI development paradigms has been taking place in the past few years. And I don't just mean in terms of the sheer number of new things coming out. The web community pioneered UI development paradigms involving functional programming techniques and immutable data, and have brought its benefits to other platforms (through projects like React Native). I personally would never want to go back to the old way of building UIs. And I suspect I'll feel the same way about client-centric data fetching when I get to try out Relay/GraphQL, Falcor, Om Next, etc in production. I really want Firefox OS to be successful for this exact reason. I don't want to have to make compromises between the best experience for my users and the best experience for myself as a developer. With a platform that makes web the native UI technology, we shouldn't have to make this compromise in theory, but Firefox OS's execution thus far has left much to be desired.
    - pjmlp 11y ago
      I don't believe it. As someone with lots of native UI experience, that has to occasionally support web projects, the web is just plain clunky and playing catch up with the RAD tooling we enjoy since the mid-90 on native platforms.
- deleted 11y ago
  [deleted]
- GrinningFool 11y ago
  > This not a big deal when pushing layout around a webpage, > but it can be crippling for app development as the app > grows in complexity and you crave native-quality > interactions Even on the fastest phones, web-based (including wrapped web components) simply don't offer the native experience. They come close, but there's always a slight but perceptible performance difference; and often a visual difference depending on what you're using. I realize people really like the theoretical write-once behavior that you get for simple apps when using a javascript platform, but I've been waiting for years for web-based interactions to provide native quality - and I begin to suspect we'll never get there. If you want native-quality interactions, the only solution is a native application and not common tooling via a javascript layer that runs atop the already not-as-performant-for-UI browser level. This makes your life harder as a developer, but gives your users the best possible experience for their platform. Alternatively, if you're willing to give your users a good-but-less-than-native-quality experience, that's the niche filled by those tools.
  - windsurfer 11y ago
    > Even on the fastest phones, web-based (including wrapped web components) simply don't offer the native experience. They come close, but there's always a slight but perceptible performance difference Honestly I used to believe this, but not after the release of the iPhone 5 and 6. Though there is no perceptible difference, it takes a lot of work to mimic the UI in terms of animations, opacity, and response actions, so most apps just use the default web technology which include things like a built-in 300ms delay, no response to clicking a link, etc.
    - SomeCallMeTim 11y ago
      > it takes a lot of work to mimic the UI in terms of animations, opacity, and response actions, Which is already done for you in Ionic -- including disabling the 300ms delay.
    - kbutler 11y ago
      I'd like to believe that, but can you cite some web-app or webview-based example applications?
matthewrhoden1 11y ago
Sworkit was supposed to be an example of a complex app for ionic, not sure what else is out there. I've used that app and can say it seems pretty solid (no crashing, locking up my phone, etc.) http://blog.ionic.io/built-with-ionic-sworkit/ http://blog.ionic.io/built-with-ionic-sworkit/ I did a pet project using the vibration feature and it worked pretty well, but haven't tried on an iphone. I can't speak for pushing the limits of the hardware though.

cbsmith 11y ago

Game developers do it all the time with C++ using things like Marmalade.

msoad 11y ago

To my experience if all your apps do is showing tables of information and forms to put the information back in (classic WinForms app) any of the cross-platform stuff will work for you. Obviously React is rendering in native and I would prefer it. But if your app is more advanced like a drawing app you should not use these cross platform stuff.

misiti3780 11y ago
or for iOS, any type of advanced animations. i like the idea of these platforms but if you building a mobile only app (like instagram when it launched) i cant imagine starting off with cross-platform tech stacks

lewisl9029 11y ago

Not sure how common it is, but I've worked on a few Cordova apps and have no native experience whatsoever. I have ran into some roadblocks that required stepping into native development to fix up issues with Cordova Plugins (specifically for background operation), but I suspect that won't be necessary for a large majority of apps out there. Personally, I find the Hosted Web App spec a very promising alternative to Cordova for app development with web technologies. You simply use the open web APIs (notifications, geolocation, camera, etc) for features that would normally require messing with plugins in Cordova, and they would just work. https://developer.mozilla.org/en-US/Marketplace/Options/Hosted_apps https://developer.mozilla.org/en-US/Marketplace/Options/Host... It's such a shame that the biggest players (Android and iOS) probably have no plans to support it natively since it would greatly reduce developer lock-in. In the meantime, the ManifoldJS project can provide Cordova-based polyfills for your Hosted Web App, but then you'd have to resort to messing with plugins all over again for the only two mobile platforms that really matter... http://manifoldjs.com/ http://manifoldjs.com/

declan 11y ago

If you're going cross platform, the key is to know in detail the limitations of this approach, even if it takes longer to make that initial decision about what path to take. Different cross-platform tools have different approaches, but as a concrete example take Corona SDK. You need no native platform knowledge and your app runs inside the Corona runtime, which makes some difficult things easy but some easy things -- third-party SDK integration, install source tracking -- difficult. And if the creator of the cross-platform environment has chosen not to support certain things, you're out of luck (and you're probably always going to be lagging even for things that are supported). On the other hand, you have only a single codebase to maintain and single-click builds for a lot of platforms. As for Cordova, we spent some time testing if the performance was sufficient when building an early version of Recent News (https://recent.io https://recent.io -- v1.0 just released three days ago!). We concluded it was not. Boot times were slow, the UI felt very non-native, and overall performance didn't meet our requirements. Now that was a while ago and Cordova may have improved, and hardware performance certainly has improved, so maybe it's a better option today.

jbigelow76 11y ago
the key is to know in detail the limitations of this approach There's the rub. If you don't know anything about the native platform then you "don't know what you don't know". The NativeScript demo shows how to pull in a native ObjC function (a string related method I think), but if you start with no background in the native libraries how would you even know when you could be leveraging a native library function instead of trying to recreate a sub-optimal approximation in JS. But if you have the foundation and know the native platform, why jump ship to JS at all? And then I'm right back where I started :)
- vickychijwani 11y ago
  > But if you have the foundation and know the native platform, why jump ship to JS at all? I'm a (native) Android and JS developer. The primary reason I'm excited about React Native is that I don't have to go through the tedious compile-install cycle for every little UI change. React Native will make prototyping/iterating on Android as easy as it is on the web. However my reasoning assumes that there will be almost no friction in terms of creating complex views in React Native. I'm curious to see if that pans out.

lhorie 11y ago

I got into native development with no experience in the iOS/Android APIs, coming from a web dev background. I did know Java and C from working on side projects, and read up on Objective-C before, though. At my previous company, all the developers doing native work had no prior experience w/ mobile development (i.e. they primarily had backend C# experience) I dabbled w/ Cordova and friends before, and did some work to wrap webapps in thin native shells earlier on, but there was always a very strict separation between the "sandboxed" webapp and the native code, if any. Webapps can and do work just fine for CRUD applications, but right now, I'm of the opinion that if you want to really leverage the hardware APIs or the native ecosystem, you're better off learning the native platform, because you get no syntax mismatch friction on Stack Overflow etc, compared to Xamarin / React Native / Ambly / whatever Also, this opinion might be unpopular among the js devs who like lightweight text editors (disclaimer: I'm one), but the heavy IDEs for Java/ObjC/Swift are actually immensely useful once you get familiar w/ their features. The static typing provided by those languages helps a lot in large refactors, in API discoverability/autocompletion and in reasoning about the codebase in general.

tmail21 11y ago
We are a startup that went the React Native route. We initially started with Ionic, but then switched to React Native. You can read about our experiences here: https://tmail21.com/blog/why-our-startup-chose-react-native-and-what-we-learned/ https://tmail21.com/blog/why-our-startup-chose-react-native-...

aikah 11y ago

You'll be limited by the widgets/apis whatever abstraction gives you. Sometimes it is enough, often it is not.

pakled_engineer 11y ago

I have zero native development experience on any mobile platform and write apps abstracted away in Scheme https://github.com/part-cw/lambdanative/wiki/Getting-Started https://github.com/part-cw/lambdanative/wiki/Getting-Started After you write/run a lot of tests to make sure the app does what it's supposed to (there's paid services for this kind of testing too) http://googletesting.blogspot.ca/2013/08/how-google-team-tests-mobile-apps.html http://googletesting.blogspot.ca/2013/08/how-google-team-tes... This React abstraction can use Chrome Developer Tools for debugging though, that's pretty awesome.

johncolanduoni 11y ago

If you stick with the tools which actually don't abstract the native platforms (e.g. RoboVM and Xamarin), I think you will learn native development quite easily. I've taken this approach, and I've had no trouble using documentation/StackOverflow to write equivalent code in Java/C#. Since pretty much all the APIs in these tools are 1-1 with the native APIs, I've also had no trouble going in the reverse direction and writing Swift/Objective-C/Java. You will still need to learn the languages, but you won't need to re-learn the APIs (which is the time consuming part). Personally, I see little to no disadvantage with using these particular types of tools, especially if it means you can use languages like Scala, C#, and F# instead of Objective-C and Java.

tluyben2 11y ago
I started serious app dev with Xamarin before I ever touched ObjC. After having implemented a ton of apps I am able to move between Xamarin/RoboVM/ObjC/Swift/Java quite easily. I dabbled with Cordova and Titanium before that a bit but that was not a good experience for me.