I'm contemplating on using React Native for a new web app. Is it possible to ship both iOS and Android apps using it?
I know that it's on the roadmap, but it's unclear to me whether it's going to be a separate open-source project (e.g., React Android vs React Native), or just one (e.g., React Native).
TLDR: Most likely you can. But it depends on your use cases.
You can aim for about 80~99+% code reuse (depending on how much Android/iOS native views/modules you use eg. Do you have custom graphics code or low-level TCP networking code; Those can only be done in native code; And expose as API to your JS code. The amount of the platform-specific JS code is actually minimal. Plus you can also use platform check like if (Platform.OS === 'android'){} to solve that) of code reuse, which is pretty nice. Dropbox and other companies have done similar projects: using c++ to build a 'shared' component between iOS and Android project, while implementing most of the UI code in native iOS(Objective-c or swift) and Android(java). But now you are doing C++ with Java and Objective-C or Swift, more language to master, more complexity and more brain juice went down the drain. And it probably took some super tough gymnastic move to make different native code work in both iOS and Android, plus debugging...
React Native just makes it a lot easier to write almost everything in JavaScript. But there is a catch, only about 80% of the JS code could be shared. In the foreseeable future, you still need to write 'platform-specific' JS code for Android and iOS versions.
That's why FB said they aim for 'Learn once, code anywhere' instead of 'run' everywhere.
But it's still very nice other than code reuse(80+% code reuse is still a big improvement comparing to maintaining 2 entirely different versions: Android and iOS ya?)
Cmd +R to refresh the app is a GREAT boost for development speed. Waiting for a big project to compile just makes you felt you were dying inside.
Declarative UI you get for free, because of using React. This is another great plus! As you don't need to 'dig' into your specific UI code that often anymore. Data changed? Just 'flush' it and UI just update accordingly. No brain juice wasted.
I just ported my not so complicated Android React Native App to iOS. And it took me 3 days. The request for and iOS version for the App came as a rather abrupt and unplanned move. So could definitely be even faster had I built the Android with a plan for iOS too. Huge win:)
Another great benefit is able to do hot code push without going through the hellish 1 week app store review process. So no more, "YAY, our app is approved. Let's release. Oh Shiiit. Critical bug and our app keeps crashing(that's gonna keep happening for at least a week before your fix is live). And you have to beg Apple to speed up the process". This is possible because the major part of the code base would be written in JS and with tools like AppHub or CodePush, you could almost instantly deploy code to your users. This is conditionally allowed by Apple.
3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code, and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple's built-in WebKit framework, provided that such scripts and code do not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store.
Lastly, as an open-source project, project longevity tends to be a concern. Not an issue for React Native. Internally used by(FB Ads Manager) and backed by FB(a dozen FB Engineers?) by Facebook, with close to 500 contributors and 25k Stars, React Native is full of life. Seeing is believing :) (https://github.com/facebook/react-native)
EDIT 1
I realized that I am apparently a bit biased and only talked about the good stuff about React Native. So do checkout https://productpains.com/product/react-native/ and Github issues to have a full picture. It's definitely not silver bullet. That being said, it satisfies most of my use case and I couldn't see me use native iOS or Android anytime soon.
EDIT 2
The Facebook F8 conference app released by Facebook (duh..) is 100% open source and they have a really nice tutorial to show you how you could have both iOS and Android native experience(90% as good as native ?), and at the same time, achieved 85% code re-use. check it out --> https://makeitopen.com
EDIT 3
You may also want to checkout Flutter and its pros & cons :)
It doesn't make sense to have a single codebase if you want a truly native experience. At the moment we have things like NavigatorIOS in React Native which provides an iOS-style UI for navigating between app screens, but if we were to just start using that on Android it wouldn't feel like a true Android app.
Therefore I'd expect to see a NavigatorAndroid component or similar when the time comes, and the same for various other components that behave differently between the platforms.
One benefit that you would get is that any application logic - maybe a store, or your backend interactions - could be written in a JavaScript file and then included by both iOS and Android.
So while you won't get that write-once run-everywhere developer experience from React Native I would expect to see a solution that gives first-class UI on both platforms while encouraging as much reuse as possible. I personally also hope to see strong build tools to help develop and ship on multiple platforms.
React Native for Android has just been released, Android folder will be creating along side with iOS folder upon creating a new project.
Just another tip as NavigatorIOS was mentioned. Facebook are not really maintaining the code for NavigatorIOS. Instead they are focusing on Navigator.
Yes. We're running it in production with about 5m registered users.
Some things are a little behind iOS but catching up quickly. It's a good wagon to be on.
React Native is designed so that you can deploy to both iOS and Android. There is a caveat, of course.
React Native has supported iOS for much longer, coming to Android only recently. So, there are some differences in terms of what is supported on each platform.
For example, if you place borders on Text, they will show up on iOS, but not on Android. In order to overcome this, you need to place a View around the Text, and apply a border to that. Luckily, React Native makes it easy to integrate separate stylesheets for each platform (or even platform-specific styling on a single stylesheet).
Support for Android is continuously evolving, so it will only be a matter of time before React Native for Android is on par with iOS. Nevertheless, this shouldn't deter you. In my experience, it's a great way to quickly develop for both platforms, and it does save some headaches.
you don't need to maintenance separate code base for android & ios. Actually you can use same code base for build android & ios. I recommend to read the react-native documentation(according to react-native version you are using) before using any inbuilt component in your code.
Eg:- TextInput component onKeyPress function supports for ios only.
if ur are using external lib check these lib support for both ios and android.
Anyway you have to configure external lib separately(install) both android and ios.
hope this will helpful.
Related
Sorry if the title wording is not clear enough. I need to deploy a very simple app on Android and iOS for a partner company (app does not need to be in App Store or Google Play) to control some machinery via bluetooth. Interface needs to be very basic and only contain a couple of buttons and some text labels that display some information (and be able to read a QR code).
We are not a mobile development company, thus I don't have any experience building apps like this, but the required functionality seems simple enough to at least look into what needs to be done.
Now, the problem is that I only know C/C++ and Python (moderate experience with the Qt framework) and am not really willing to learn both Java and Swift. I might consider learning Swift specifically for a simple project like this, seeing as iOS development is very much tied to their platform, but Java is out of the question. I've looked around and there seems to be a way to write both of them in Python and deploy to each platform, but something tells me it's not really worth the incredible amount of problems that could arise. I need your help with some advice on how to handle this project:
Can a cross-platform app be developed with python(or C/C++) and deployed to iOS and Android (thus halving the overall development time) whilst keeping a sufficiently tidy aspect and bluetooth communication?
If not, can I develop an Android app using C/C++ or Python without immense hurdles? I'd prefer Qt as i'm already familiar with the framework, but i suppose anything does it.
When developing an Android app under point 2, is it possible to see how the app looks like without installing it on the phone for every change in code?
Sorry if the post is too long, am really curios how difficult would a task like this be. I dont want to waste my time learning 2 new languages for just this project nor do i want to end up delaying the partner company with beginner problems caused by my scarce knowledge of a new language.
I really wouldn't suggest cross platform for this kind of project. The bluetooth stacks and APIs are going to be tremendously different, minimizing ability to code share. The UI stacks are completely different. Really using anything but the native tools on iOS can be particularly tricky. Python in particular is hard, because its not meant to interact with either platform. C would be easier, as both Java (via JNI) and Swift (via objective C to C bridges) can call C code. However the UI layers of the two are so different that it would only be useful for business logic, I would still recommend writing the UI in the native platforms.
If you were going to try and do cross platform, I'd suggest react native and javascript, merely because it's the most mature of the cross platform products. That said, their bluetooth stack is likely non-existant or poorly developed because its not the type of thing used by many of the type of apps that choose react native, so you'll likely have to dive into the deep end and learn how to make modules.
Given that this is going to be a company specific app not on an app store- do you actually need to support both OSes? Or can it be done on company devices of a single type? Pushing back on that product requirement might be your best bet.
We want to develop mobile keyboard app - (Third party keyboard) that have some unique features (such translate on the keyboard).
We would like to know if there is a way to developed it once both for IOS and Android, with Flutter, or any other solution?
There's a long and a short answer to this. The short answer is basically no, it's not feasible at this time to do this.
The long answer is that it may be somewhat possible but with a fairly large amount of work for you to do. You're going to have to first create and appropriate project type in android and ios, and then import the dart code & set up the build. You may be able to start with a normal flutter application and modify the xcode/gradle builds to match the specifics for ios/android, but I'd guess that's somewhat unlikely. So you'll probably still have to maintain two separate projects, but which could import the same dart library for the UI.
Because Android and iOS use different APIs for their keyboards, you're going to need to write a Platform Plugin or at least method channels which communicate between your app and the native code, for each of iOS and Android. You'll also probably have to embed the flutter view yourself - see this example as I'd bet the normal FlutterApplication etc won't apply.
I'd guess that on android you could probably get this to work eventually with a lot of work (depending on how familiar you are with android, platform channels, and integrating libraries such as flutter's into the build); on iOS you might have luck but it's somewhat conceivable that iOS blocks certain features that flutter needs in the keyboard for performance or security reasons - just guessing from my experiences developing apps in native iOS although I haven't done a keyboard specifically.
That being said, if you do try this I'd be interested to hear the results, and if you were to go about it in a somewhat generic way that could be re-used it would be of great benefit to the flutter community!
I’ve started to dig into integrating React Native in existing apps, and I mean real industrialized apps (iOS and Android version of a same app) that we wish to refactor with as much RN as we can for bringing code bases together (there is also an existing web version).
We are pretty convinced that including multiple RCTRootView sharing the same bridge is the best approach for us, starting from the basic content views (where sharing code bases is easier and more profitable) and iterating to turn more and more parts of app in RN (Animation, Navigation, …).
But when we’ve investigated this approach, several questions popped out, both technical and organizational.
First of all, although we don’t want to be iOS-first or Android-first, the Android platform doesn’t seem to have the same maturity of the iOS platform for this kind of work. We faced some problems like:
The ReactRootView doesn’t follow the React lifecycle, unlike iOS’s RCTRootView, there is no API to update props : https://github.com/facebook/react-native/issues/6303
It’s impossible to include a ReactRootView inside a native scrollview. This limitation exists from the day one of the Android release (see https://github.com/facebook/react-native/issues/9022)
The following is not really a “problem” but it adds some doubts about the Android support.
The iOS part of the integrating doc clearly mentions that it’s possible to init a view using an existing bridge (initWithBridge, the API is explicit too).
On Android, the same doc mentions that multiple views can share the same ReactInstanceManager, but if you expose 2 components in your bundle and use it, you have to call twice startReactApplication and you’ll see 2 lines in Chrome console
Running application "XXX" with appParams
Running application "YYY" with appParams
Sounds not very optimized to me… Did I really create 2 entire “RN apps” here ?
That being said, we are looking for feedbacks and answers :
About the Android platform, is it reasonable to synchronize the refactor on both platforms or we’d better turn the iOS app into RN and then the Android one ?
How far can we go in RN views displayed simultaneously ? 10, 20 views at a time ?
Our app is “data-oriented”. Is it a good idea to move the data-fetching in a Redux app in the RN world first ? I guess we have to expose data and notify store updates to the native world: what is the most efficient way to do this ? (Native modules makes the communication in the other side easy, native toward RN, but they seem not helpful for this purpose).
Also, how to organize the VCS ? Is moving the 4 code bases (iOS, Android, Web and the RN bundle) in a mono-repository a necessary move ?
I want to develop application in android and iOS both.
But i am confuse between native development and development using react and node.js etc.
Please help me to choose (If possible specify reason).
P.S Here cost is not an issue.
If you need high performance and attractive UI and don't want to be blocked by some functionalities that may not br provided by cross platform, I recommend you to use native platform. But if your app doesn't need to be very attractive and doesn't need too much processing, then you can use cross-platform. Actually for many features you need to add plugins if you are building cross platform app and adding number of plugins makes your application slower.
OK, well there isn't much data to go on, but there are several options if you want to write cross platform apps.
There is:
Sencha Touch - HTML and JavaScript
PhoneGap - HTML, JavaScript and CSS
QT - C++ and QML
Appmethod - C++ and Object Pascal
Xamarin - C#
Visual Studio - looks like you can do C# or C++, or Unity for games.
and probably a lot more...
Why would you choose one of these instead of writing in the native language for the platform?
Well, the pros seem to outweigh the cons. If you are targeting several platforms, I would choose one of the options above, simply because you only have to write everything once. If you did it native for each platform, you would write everything twice or maybe three or even four times. Using one of the above tools will be much easier and save you time, and they might be just as seamless and workable as native development.
To simply answer your question, If you would like to be able to write your app once, and be able to manage all future updates by managing only one code base, do cross platform using one of the above tools. The only downside is that you might have to learn a new language (but with a place like Stack Overflow, learning new languages is pretty awesome). It will save you time in the long run.
Although I am comfortable with Java, I have much more experience with web development. I am looking to get into programming simple Android games.
Should I just program everything using Javascript/HTML and forget ramping up on Java/Android SDK? I guess my question really is, what are the limitations of PhoneGap? What are some things to consider, etc.?
Some advantages I can think of:
More selection in terms of game engines for HTML5/JS
Faster ramp up time
Automatically deploy to all major platforms
The biggest pro for phonegap is that it takes advantage of your web development experience. I think what most people seem to miss (or ignore) is that there is no advantage in avoiding phonegap for an android only application! You can still write as much native code as you want to, mixing and matching phonegap as you please.
I am writing an Android app that uses text to speech. Because Phonegap doesn't support this in their API, you might think that Phonegap is a bad choice, but actually it was quite easy to call the Java code I need from javascript:
Java code:
public void onCreate(Bundle savedInstanceState) {
//boilerplate and TTS set up
...
this.appView.addJavascriptInterface(this.speak, "speak");
...
}
public void speak(String text) {
this.tts.speak(text, TextToSpeech.QUEUE_FLUSH, null);
}
Javascript code:
speak.say("hello world");
Pros for Phonegap:
deploys to all major mobile devices
sounds like it best fits your skillset
covers most available platform APIs with a uniform code base, no need to learn each one
PhoneGap Build (https://build.phonegap.com/) and Cordova (https://github.com/brianleroux/Cordova) are making it even easier to deploy to multiple platforms
Pros for Android:
Better performance
No limitations on which APIs you can use (i.e., video)
Defined toolset and workflow
native UI components
Fragments API and native layouts make handling different screen sizes easier
It really comes down to whether or not you want to be an Android-only developer or not. That first pro for phonegap is HUGE is you plan to develop for multiple platforms.
I personally have major concerns over PhoneGap apps performance compared to that of a native Android app. The admittedly small amount of testing that I have done makes the PhoneGap version feel very unresponsive compared to native. I don't see how this doesn't translate to a poor user experience. Even PhoneGaps packaged sample application runs poorly.
I was very excited at the possibilities that PhoneGap appeared to open up, but I don't feel like it's there yet. I don't feel comfortable committing to a large project on PhoneGap.
No WAY! Adobe has their cloud build which has a 9.5 MB file size limit. And, they are discontinuing support for other types of build.
I have just spent the past week or so developing a simple Android app using PhoneGap. My great hope was to be able to recommend this product for use in our department as a "write-once, deploy everywhere solution."
In practice, it was more complicated than I would have hoped. I did manage to get an Android version of the app done, but I found a lot of quirks in using basic stuff like getting it to include css and the jquery mobile framework. I kept thinking that this was just my learning curve but a lot of the tutorials I found online were outdated and didn't work in the version I downloaded. The biggest surprise was that you can't link to external documents without using a plugin such as childBrowser, which is a huge drawback.
I tried today to port my app over to iOS and could not get past step one with importing css. I couldn't find any support documentation on this basic step. It's frustrating because this is a simple app that I could craft as native in Xcode in a day or so. It looks like it will take me a lot longer using PhoneGap.
PhoneGap looks really promising, but at the moment I don't want to use it. It's just a question of time. Why would I want to take twice as long on something? It might be a better choice in future versions