So we have an application in production running on both Apple store and Google Play store. We originally built it on Xamarin and hope to port it to a newer infrastructure. We looked at some avenues such as Ionic + Angular with a backend to MongoDB Realm. Our biggest concern for frontend capabilities have been offline data support, image editor, and barcode scanning. We are hoping to go to a Progressive Web App this time and not have to deal with the stores. In our recent research, we found Camera and Permission API's on browsers is lacking, especially iOS (Steve would be upset if he was alive). Recently we noticed Flutter is growing fast and web support is getting better, though their camera API's for iOS and some Androids still have issues. Ionic's camera support is not perfect but seems to be solid compared to Flutter. Anyone else having issues with camera API support (especially Flutter)? We would like to have a stable camera/permissions on the web if possible but we feel the timing may not be right. Would like to hear others and their thoughts and thank you for your time!
Related
We are excited to start developing mobile app using Flutter and backend applications that are running on Django with REST APIs. Our understanding is that once a mobile app is completely developed, we can simply launch the UI on a web browser as well with probably minor changes? Is this really true? if it is true, does our mobile app developer have to start coding the app to make it compatible for both mobile, web browser and desktop since from the beginning so that we don´t have to spend extra cycles to make the UI compatible with web browser and desktop? Or is Flutter supposed to be compatible by default for any UI clients ( Web browser, smart devices and desktop)? I would appreciate it if someone can confirm and point me to a relevant article?
Best regards
There ara small adjustments you need to make. For example some plugins are not supported for web of vice versa. So you need to avoid from using them.
Also while building UI, if your developer does not make it responsive, you would have a ugly mobile UI. So my advice is both web and mobile should go on hand to hand to avoid and end product mistakes.
Note that there are even small differences between Android and IOS
colleagues, due to the pandemic, virtualization was ahead of us, and now many companies are looking to work online and do live broadcasts within their applications.
So I am looking for, and asking you if you know or have any experience with live audio and video transmission system that integrates natively with Ionic (Preferably version 5, and Angular) and Capacitor, In order to Ionic developers can make apps with that feature.
You can integrate with Zoom, We did that and it works decently well.
Now that we need better performance we are switching to Flutter, but to answer you in short, you can do it easliy with Zoom.
Here's a link to help you out: https://marketplace.zoom.us/docs/sdk/native-sdks/ionic/getting-started/install
I was wondering if someone knows what has faster performance speed ionic2 or nativescript? Does ionic2 still run on top of Cordova's webview? Or is it similar to nativescript?
Ionic 2 still uses the webview. Things have gotten faster and newer devices are faster of course. Ionic is doing some great stuff, but you'll have a better performing application using NativeScript IMO. I don't have any benchmarks right now but I can assure you if someone does have benchmarks NativeScript will likely win on all fronts because it's not a webview. It's similar to react native and xamarin. As with most choices it depends on what you need and factors of time, cost, etc. All of these frameworks have pros and cons. Personally I settled on NativeScript since I didnt know react for react native, and i wanted to have native UI not native looking components in a webview. However for a quick prototype or an app that you might want to reuse as a PWA (progressive web app) ionic is a good choice in that regard. You can of course get code reuse with them all using angular and react in react native but the UI is different since its not shared with the web DOM. Hope that helps some.
So that answers your question, here is a xamarin and NativeScript comparison article from Burke Holland (works for telerik) but the tests seem very impartial as I've used both products and I am aware of the items he goes over https://www.nativescript.org/blog/details/nativescript-and-xamarin
Ionic's payload is smaller with the phone already carrying the browser.
The performance of Ionic 3 is simply superb.
I have noticed an unfounded snobbery when it comes to webview based frameworks saying they're slow. Most people are not making the next Facebook or Youtube but more generally applications for CRUD operations with a little bit of mobile goodness.
That's the audience for this product.
Hi I have been recently exploring some of the Javascript mobile frameworks that can be used for developing mobile web apps like Sencha, JQTouch, JQuery mobile etc.
I know the adv and disadvantages of both.
I just need some recent stats which show the market's adoption or opinion.
I tried three ways to develop mobile applications.
First method is to use frameworks that will take your html/css/js files and package them into mobile applications depending on your targets (BlackBerry, iPhone, Android, ...). I used PhoneGap (known today as Cordova). I didn't like it at all because the UI's rendering is so ugly on some devices and the user experience is broken. I had to use it with jQuery Mobile because it gave me a good UI design start. I tried some Phonegap Android generated applications on my personal device and it's really horrible. Some of them got rejected by Apple because of that ...
Second method is to use Appcelerator Titanium SDK. One word to sum it up: Awesome. One language to use (javascript) to create your UI/Controller. It's so easy to learn, so powerful to develop with and it has many out-of-the-box functionnalities (like facebook API, Yahoo Query Language, ...) that will allow you to put in place solutions easily for both Android and iPhone. BlackBerry is coming soon. What I liked the most is that it converts the written Javascript into the targetted platform with the default UI. It's really great. And, above all, the UI is easily customizable (with a css like system).
Personally, I put in place apps that can: Take a photo with the device then send it to a remote server, send messages to twitter/facebook, advanced geolocation, etc.
Third method: Native! It would take time if you target both iPhone and Android but, the big advantage is that you can create anything you want without being tied to a Framework for areas such as games, augmented reality , etc.
In my opinion, if you want to create simple applications with some nice features (weather, twitter feeds, sending on a facebook wall, ...), use Appcelerator Titanium SDK.
It converts your code into NATIVE.
If you have time to spend learning native languages, do it. It's the best way ;)
Hope it helps.
Regards.
I've summed up my thoughts on the whole "native vs. web" discussion in a blog post here: http://www.springenwerk.com/2011/09/thoughts-on-mobile-ui-design.html
In a nutshell: You can't get around getting to know the platform you are targeting if you want to provide a great user experience. Plus, you shouldn't try to mimic native UI/UX in a web application, it will only disappoint your users.
here are some pros and cons of native apps vs. web apps:
Native apps:
Native apps have more security
Native apps have higher user engagement, it has higher click-through rate (CTR) among the ad-serving publishers
When it comes to aesthetics and overall user experience, it is incredibly difficult for web apps to trump native apps
you don't have to buy a server and maintain it, therefore, for small businesses it is the ideal solution, not web apps which require a server.
Web apps:
it's cross platform - that means your one app will work on both iphone and android
cheaper and faster to develop and maintain
you will find programmers easier than native apps
updates are easier
Check out this post for some more opinion - http://www.thorntech.com/2013/01/html5-vs-native-apps-which-will-win-the-mobile-app-development-battle/
In particular, the last paragraph is worth noting. If you go down the path of building an HTML5 app, it is worth having some type of background "syncing" of content so you are not always pulling it from the web in real time. The app will be much more responsive if you load HTML pages from disk.
From my experience, the success rate of a native apps are much better than html or javascript based ones. I do not have sufficient numbers to back it up, but these are some issues that may crop up when trying to build html5 apps for different platforms. e.g.
Browser OS or webkit differences can cause unexpected bugs, css issues that could take quite a while to debug.
Your app is running on top of a webkit browser engine which takes up additional resources.
Older or non-smart phone devices may not have a modern webkit engine.
Nevertheless if you have good web skills over native, then getting an app to the market the quicket and cheapest route would be html5. Some apps lend very well for html5 such as data listing, and text content driven apps. I have written a writeup on HTML5 vs Native on my blog. Hope its useful.
I think about starting from scratch building a small application fullfilling two technical requirements:
should be usable on iPhone
should work offline
There are two obvious alternatives here to choose between
A real iPhone application with offline capabilities
A web app using HTML5 offline, Google Gears or similar
Having no iPhone app development experience (I don't own an iPhone), i wonder which way would be the easiest to go?
What are the learning curves for building offline HTML vs building an iPhone app?
Honestly, it depends what your app is going to do.
MobileSafari supports all the HTML5 offline stuff, so you could store data in a clientside SQL database, cache the application clientside, etc... The mobile Gmail app is probably the most notable example of that, giving you full-featured access to your Gmail even when offline. You can also use geolocation through JavaScript APIs that were added in 3.0. Web Clips let your web app share the home screen with native applications too. There is more on using web apps on the iPhone on this Stack Overflow post.
Obviously, doing a Web app will be of interest to people who like dealing with HTML, CSS, and JavaScript (and possibly whatever language is running server-side). It is possible to do really neat stuff with offline Web apps, but its performance won't be as good as that of native apps, especially on pre-3GS devices.
Developing a native application will require you to learn Objective-C (or C# as soon as Mono Touch is available to the masses) and pay a $99 fee to be allowed to test on-device and deploy to App Store. A lot more of the system is exposed to you through the various APIs, such as the camera, compass, multitouch, and so on.
Objective-C is pretty simple to pick up if you're familiar with Java; you only really need to get used to the square bracket syntax and memory management and then it's pretty straight-forward.
Then there are the hybrid systems, like PhoneGap, which expose more of the device's APIs, provided the Web app runs in a special container app. It is also crossplatform, so you could also deploy the app on Android and BlackBerry if you wanted to. This still requires you to pay the App Store fee, but if you're more familiar with Web development, this gives you the best of both worlds.
I can't tell you too much about HTML apps in general, but I can tell you that the API for the UIWebView is extremely minimal, and of course there is much less you can do than in a native iPhone application.
An HTML5 offline app would have security issues as you would have to hard code your oauth secret into code that anyone could see ( by clicking view source, or inspecting in Firebug ). You could simply use http auth, but then you get the ugly "from API" credit with every tweet sent from your app, and also that ugly http auth popup from the browser.