I'm currently graduating at a small company which makes and sells accounting software.
My task during my graduation is to make a Mobile application which supports some functionality of this software.
For instance: making a report on site and uploading it to the server,logging hours worked, retrieving sales information etc..
I'm currently doing research on which platform I should deploy but I'm getting confused in what shape my application should be made.
I can't make a choice what I should recommend, Web app or Native app?
I need help making a recommendation:
Security is important. (we deal with confidential information)
Maintenance is very important. (they will have to support it in the future and have low resources available. (small company))
Development costs (I have no clue here.)
User experience (Because this is a business app, is a web app good enough?)
The business market here is currently very iOS (Apple) saturated (about 80%) but I do need to think of the future. (Android, WP7)
So What do u recommend with the given information, web or native? Do I need more information before making a decision / recommendation if so, what sort of information?
ps I think this question belongs on stackoverflow, if not please move it to the appropriate site.
For what you're looking to accomplish, I'd recommend taking the mobile web app route. Here's why:
Security is important. (we deal with confidential information)
You could make a case either way, but I feel that a mobile web app is better for security. Like Ganzolo said, it can have as much security as a typical web app. Also, since it doesn't store data on the device itself, you won't have to worry about a data breach in the event of a lost or stolen phone (assuming you're not using HTML5 offline storage).
Maintenance is very important. (they will have to support it in the future and have low resources available. (small company))
Mobile web apps have an advantage here. If you built native apps, you'd have to build and maintain separate apps for each platform. On the other hand, since one mobile web app reaches all platforms, you'd only ever have to maintain one app. Also, you won't have to update a mobile web app with each OS update, like you would with a native app. If you want to go one step further, you could even build a mobile web app with separate presentation layers for smartphones, tablet, and PCs (like this). That way, one mobile app would look different (yet native) on any device, but you'd only have to maintain one underlying application.
Development costs (I have no clue here.)
Depends on how many platforms you want to reach. If you're building for one platform, the costs are similar. If you're building for multiple platforms, mobile web apps are far cheaper. One mobile web app reaches all platforms, whereas you'd have to build a separate native app for each platform.
User experience (Because this is a business app, is a web app good enough?)
You'll get a better UI with a native app, but a mobile web app should be more than sufficient for most business apps. Use a good mobile framework (like jQuery Mobile), and you can build a mobile web app that looks and feels almost native.
The business market here is currently very iOS (Apple) saturated (about 80%) but I do need to think of the future. (Android, WP7)
Mobile web apps are a much safer choice for the future. Who knows what the mobile platform landscape will look like in 2 or 3 years? Maybe WP7 will be popular. Maybe some new OS will be popular. It changes so fast, there's no way to know. The only thing I do know is this: The web will still be popular. If you build a mobile web app, you insulate yourself from all future mobile OS battles.
I hope that helps.
My personal opinion would be to go for a web App :
• Security is important. (we deal with confidential information)
Sercurity in a web app cannot be worse than security in a regular website (like online banking)
• Maintenance is very important. (they will have to support it in the
future and have low resources available. (small company))
Maintenance is really easy for a web app since you can make updates without going through the process of submitting your app to the store and waiting.
• Development costs (I have no clue here.)
Development cost will be lower with a web app as you'll have 1 code for every phones (and most of them are using webkit which will be simplier)
• User experience (Because this is a business app, is a web app good
enough?)
It's hard to answer this question without knowing your project but for simple UI it can be good enough
• The business market here is currently very iOS (Apple) saturated
(about 80%) but I do need to think of the future. (Android, WP7)
Yes you need to think about the future that the most important because you can only do simple functionality in web apps. So if future requirement, will have more complex functionality then you'll have to move into native apps.
Hope I've been helpful
In my experience, web apps always tend to be sluggish on the UI front. I would always opt for a native app, if you don't have to support multiple platforms at once (iOS, Android, generic).
Security: Make your app connections over SSL
Maintenance: The only problem here is that you may have to wait 7 days for App Store approval for native apps
Development costs: Depends on who makes the app, shouldn't be too different.
UX: Defenitely native!
Multiplatform: As I said, for multi platform a web app is probably best
If you opt for a web app, make sure the user doesn't have the impression of "the app isn't doing anything" while loading stuff.
Related
Client wants to publish an iOS application as a starting point for their product which at the moment will be entirely single web view driven. There will be some networking calls to resolve some of the URLs, but the sign in and all content will be entirely on single web view. On top of that there is push notifications, which will redirect user to different parts of the website based on payload.
* They have an existing Android application that does this and they want an iOS counterpart.
Appstore guidelines state an iOS can't be a repackaged website and will likely get rejected. The purpose of this question is to find out if any of you fellow devs have gone through similar experience, and if so what was the outcome / recommendations to proceed.
The mobile apps will have native components in future, but at this moment as a starting point it's not the case.
Thanks
We looking to develop an "App" which would have the ability to record the details of a damaged car for assessors. The idea is that a small number of assessors would have company iPads. Then when car is damaged and returned to the car yard they can visit take photos, enter some details and then upload them into the main system later. Some of the car yards may be in areas that do not have internet coverage, so offline capability is required.
Our initial thoughts were to develop an IOS App for installation on a small number of company iPads. The App could access the camera to take photos and then when the device has internet access upload the photos to the main system. However this solution could prove too costly (regarding development costs) for the customer.
I have read about PWAs and caching data, but the caching seems to be for offline read access.
If we installed chrome on an iPad and then installed a PWA then presumably
The PWA could store pictures up to 128GB * 6% = 7.68GB?
If stored using the File System API then (as long as there is plenty
of space on the system) the data will be persisted (my understanding is there is no time limit)? Or would a different type of storage be more suitable.
The offline data is obviously important (may be required in court) so are there any other concerns around persistence & stability before the images are uploaded to the main system?
Note we would prefer to use iPads (as the customer would prefer these) but we could consider other platforms.
At this stage I am really trying to find out if a PWA accessing the offline storage is likely to be feasible, practical and stable on the platform?
Firstly, iOS restricts third party web browsers (or any app that displays web pages) to using its own engine - installing Chrome on an iPad will not enable access to any web APIs that iOS/Safari doesn't already support.
So in particular:
File System API is not available on iOS, even if you're using Chrome
Cache API has a storage limitation per website of 50MB
IndexedDB has a storage limitation per website of 500MB or half the device's free space (whichever is smaller)
PWAs and their cached data are automatically wiped from devices if not used for a few weeks
the "navigator.storage" API for requiring durable data is not support on iOS, even if you're using Chrome or Firefox.
My first thought would be that if you are only going to support iPads and indefinite offline storage is a requirement, you are probably best of with a native application. Keep in mind that for this kind of application you would need the Apple Enterprise Program, which is more expensive than the regular Developer Program.
However, if you do want to use a PWA, your best bet for local storage would be the IndexedDB. As per the comment by skybondsor, browsers do indeed limit and possibly evict data after a while, according to ADM webdocs.
But reading your question, I get the sense that you do not really need persistent local storage, but rather a method ensuring that your data will eventually end up on the server. You can accomplish this by exploiting the Background Sync methodology. This allows your application to delay the upload to when a stable internet connection is available.
If I have both a native app and a progressive web app using web push notifications powered by service worker, is there a way to prevent a user from receiving duplicate notifications if they opt in to receiving notifications from the web site and also have the app installed?
In short - there is no easy way to do this today.
There is a discussion on Chrome here on this: https://code.google.com/p/chromium/issues/detail?id=402223
The last comment from October 2015:
For now the safest minimal solution is for sites to provide an easy
opt out mechanism (which we strongly recommend you do anyway!) so
users can turn off notifications from one platform
Another possible heuristic based solution is to take some measure for
which interface (web or native) the user most often uses (or most
recently used) and only send to that. Combined with grouping these
devices by rough screen size should give a pretty good approximation.
The issue is that if the user has two similar sized devices and uses
native on one and web on the other then notifications will only be
delivered to one, which is an edge case.
We've also been discussing building an API so sites can tell whether
their corresponding native app is installed to avoid this case, but
need to start discussing that with other browser vendors to see if
they'd be supportive.
I hope this is not off topic for StackOverflow since it is not just software development related but also marketing. But I guess this problem is something we developers are all confronted to.
To monitor and market our iOS app, we use a bunch of third party SDKs:
Google Analytics to understand what's happening
a push notification system (e.g. Urban Airship)
a "smart" review prompting engine (e.g. Apptentive)
a testing / crash reporting system (e.g. Testflight)
should you want to run app installs ads, you also need the FB SDK, an SDK to track Twitter conversions, etc.
you may also want to track where other installs come from via something like Tapstream.
So we are already running more than 6 3rd party SDKs in our app, and it does not feel right:
each of them will do some kind of hand shake every time the app is opened
it's as many potential issues
each of them will have a different web interface
Is there a way to optimise all this, i.e. to have just one SDK doing most things? Or does someone know of a lib to wrap all this stuff under one lib for instance?
There is no getting around a few of these. If you want to talk with FaceBook, Twitter, etc. You will need their SDK no matter the 3rd party SDK you choose.
You could actually write your own setup to track and deal with everything, but there are those that have done it before.
For example, Parse will do:
Analytics
push notifications
a "smart" review prompting engine (you can do this yourself by reviewing the analytics)
crash reporting system
it also uses FB SDK, Twitter SDK already to help with user logins where users my want to use their credentials from their sites on your app
user login
cloud database
You could technically throw an "event" into the analytics to track how many folks are using your app that was installed from x store. However, this would require a different version of your app for each store. Sounds like an interesting idea none the less. Tapstreme and others are basically marketing though, not really something required to do something specific. You will need an SDK if they are tracking something specific themselves.
one web interface
There are multiple systems built like this. they are called BaaS or Backend as a Service.
Hope this helps, Cheers
Ok, I have a client who is a utility provider (like power, water, etc). They want their customers to be able to pay their bill from an iOS app. Since this isn't a product will it be okay to use an alternative payment gateway using WebView?
This specific usage sounds fine. Apple doesn't allow you to sell app content through anything but the store, but taking payment for an entirely external service should be fine, there are dozens of similar apps for general payment processing (LevelUp, 4square, etc.), and this is the same sort of thing, just for a more specific debt.
That said, if all your app is is a WebView wrapper for your site, Apple will reject it because of that. An app that wraps a webview must additionally use a nontrivial amount of native functionality.
In general, if your application is just a UIWebView embedded in a UIView, it will almost certainly be rejected. What is the benefit of an application embedding a mobile version of the website, compared to just loading the mobile site in the default Safari web browser?
If you are going to do this, Apple requires that the application be more than just a web browser loading a default URL. This can be one component of the app, but it cannot be the only component.