I am in the planning and design stage of an idea.
Think of foursquare or quora as the product, I know they are completely different but the dynamics are similar. Crowd-sourced social applications that require user input and engagement.
Given this, should the "product" be a mobile app, website, or both? Are most ideas successful as websites first, with mobile applications as an afterthought? Is the mobile app just a companion or is it the whole experience?
Most importantly, how can I make this decision prior to development? Is there some sort of litmus test to determine which of the 3 options will work?
Any tips, advice, or guidance is much appreciated.
Creating a great mobile app is hard. Now, do it twice, to support Android and iOS. But wait, are you going to support Blackberry? What about once you get outside the US? What about Windows Phone?
With a native app, you do get some advantages. You in general can create a richer experience, have stronger off-line support (if appropriate), widgets, etc. But that flexibility comes with a cost, a significant one, and one you'll pay over and over again. If you can create a purely web version of your product, you're going to have a much easier time supporting a wider range of handsets out of the gate, and nothing precludes you from building native apps down the road. Start out with the app as your primary access method, and you're really creating a lot of up-front work for yourself. Start with the web as plan A and supplement with apps, unless there is a great reason to do otherwise.
Related
I am pretty new to iPhone and spent some months on it but.....But i think my learning went waste when i read about web application for iPhone...These can be developed even with a nil knowledge of Objective c...
I am very shocked about that what is need of an iPhone native app....i mean iPhone developers are less required now?
please suggest........
Well it's not that simple.
You can do quite a lot on the iphone with html5 and css3. Especially effects using webkit transforms are really impressive and performant. Furthermore, you can for example access the GPS hardware using javascript.
On top of that it is also possible to write 'enhanced' webapplications using a framework like phonegap (http://www.phonegap.com/) that enables you to use things like the accelerometer or tab controls via javascript as well as makes your webapplication into a compiled app that can be destributed via the appstore (and used offline).
Combine these features with a framework like sencha touch (http://www.sencha.com/products/touch/) or the currently developed jquery mobile and you can write really usefull applications that feel like native iphone apps using mostly just web technology. Another benefit is, that these applications can also be ported to android devices rather easily.
But this all comes at the price of performance. Thomas Fuchs blogged some of his experiences in speeding up web applications for the ipad here: http://mir.aculo.us/2010/06/04/making-an-ipad-html5-app-making-it-really-fast/
Generally speaking it is extremely hard to write realtime or image heavy applications that perform smoothly on the ipad and it is close to impossible to match the performance and smoothness of native core animation effects.
Furthermore things like file access, core data (some hacks exist) or direct access to the 3d hardware require you to write cocoa code anyway.
In my current applications i usually start with a bare-bone ios app containing some webviews. Then i sketch up features using web technology and implement performance critical parts using cocoa
I have no idea what you're talking about. Yes, there are two ways to develop applications that can run on the iPhone: web applications and native applications. Yes, web applications don't require you to know Objective-C. Yes, Objective-C is more difficult than HTML/CSS. But you can't do everything in a web application that you can in a native application. So no, native apps aren't going anywhere any time soon, and neither are the programmers who write them. They are no "less required" now than before.
It's the same thing on the desktop. You can write web applications that the user runs in their web browser, or you can write a native app in Objective-C. There is a place for both, but native apps aren't going anywhere any time soon.
You can choose to take the easier route, if you choose, but you won't end up in the same place as someone who has taken the time to learn Objective-C and written a native app. Whether you need that additional latitude and functionality is up to you. As long as you're making threats like "help me or I will leave this field", I suspect that very few of us will miss you.
A huge portion of possible apps that don't require the highest performance, special device hardware features not yet supported in HTML5, nor the security of compiled code, can be done as web apps.
But if you need the highest frame rates or a lot of number crunching, a native app can run from around 20X to over 200X faster than Javascript in a web app. A native app can also do audio processing and real-time video analysis, background VOIP or GPS tracking, use other brand new iOS APIs (MIDI keyboard support, etc.), and include lots of compiled libraries and other unix code that just isn't available in HTML5.
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.
My company built its own project management web application. It's like basecamp on steroids. The core features of this application are:
create task lists
assign tasks to team members
track hours against task items
I am looking to build mobile application(s) as an extension to the web application. The mobile applications(s) must:
reproduce the features mentioned above
connect to the same database as the web application
retain drag drop capabilities
provide a rich user experience equivalent to or better than the web application
work on iphone, droid and blackberry
Given the requirements above, how should I approach the development of this mobile application? There's about 20 smart phone users in my company: 8 iphones, 7 droids and 5 blackberries.
I've heard of development frameworks like Phonegap that allow you to develop in HTML, Javascript and CSS. The software then works cross platform across blackberry, iphone and droid. If I am an average/slightly-above-average programmer, will I be able to build a high quality cross platform mobile application with PhoneGap (or another x platform development framework) that meets the above requirements?
Or should I build each iphone, droid and blackberry application independently?
What's the best approach? What are the trade offs?
John,
Well it sounds like you've got a bit of work ahead of you! When you have an existing web-based application, there are two basic approaches to getting your app available on any particular device: you can (1) write a native app that implements the functionality you want for each device you want to support or you can (2) write a web-based "wrapper" for your existing app and serve the content as HTML/CSS to those same devices.
Option 1: Build a native app for each platform you want to support
As for the first approach, the benefits can be great. By using each device's native frameworks, you have the complete ability and flexibility to take advantage of the best features of each device. Your app's views can also render faster, since all you will be fetching from your server is the data to populate the views with (i.e., you do not have to load images, HTML templates, or CSS files at all).
The drawback with this approach is that it inherently requires each device to have its own application. So if you're supporting a web app, an iPhone app, an Android app, and a Blackberry app this means that you have 4 completely separate codebases to maintain. If you add some sort of new feature to your web app (which you presumably will at some point), you will also have to implement that new feature in the three other separate code bases. Given the fact that these devices can have different interaction models, this could pose a challenge. Another drawback here can be distribution (i.e., you may have to go through a review process for something like the iPhone app store depending on how you want to distribute your app). It also means that the amount you will have to learn is quite a bit greater since each device has its own API set and programming "philosophy".
Option 2: Write a web-based "wrapper" for your app (perhaps using a library)
This approach also has a great deal of benefits. First off, if you use a framework like PhoneGap or Sencha Touch or Rhomobile, the big benefit is that you theoretically write the "mobile app" code once and it works across each of the devices supported by the framework. Compared to writing a native app for three platforms, this is a lot less work.
Downsides here are as follows. This approach runs as a website in the device's browser, so you will not have access to all of the functionality of every device. All of the great stuff in the iOS and Android API's will by definition not be available to you. You are also somewhat limited here with regard to local storage, but this may not be a great concern to you given your web app. Another drawback is that there will be more bandwidth required from your server this way, since you are serving all of the HTML, images, and CSS that you would otherwise not have to with a native app. Depending on the number of users and complexity of the pages, this could be significant to you or not. Another downside here is that you cannot go full-screen (with the iPhone in Mobile Safari for instance there is always a toolbar at the bottom).
General Concerns
One thing that concerned me reading your question was your list of requirements. Reproducing features and connecting to a remote data store are things you can definitely do with both native and web-based mobile apps. But "retain[ing] drag drop capabilities" is not. With an iPhone, for instance, you can use handles in a UITableViewCell to provide a way to reorder lists, but full-on drag-and-drop is not really something that fits with a mobile device's user interaction model. You may have to re-think this one.
The requirement to "provide a rich user experience equivalent to or better than the web application" is also a bit troubling. While phone-based apps can have really streamlined ways to get at and manipulate data, remember that you are designing for a screen that is a few inches square. It is physically impossible to provide the same breadth of information in an organized manner than you can with a 21" HD widescreen monitor.
Remember that you're designing here for mobile, so you want to take advantage of the available platforms but remember that you're dealing with small screens and limited interaction methods (touches, swipes, and gestures).
My recommendation is that if this is your first time at this, you want to support all of these devices, and you already have experience with the web, I would suggest taking Option 2 and using one of the above-mentioned frameworks. It would be the easiest way to start and there wouldn't be any radically different concepts for you to have to learn.
Good luck!
An additionally comment on what Neal L posted above, with Rhomobile you can access the devices native capabilities as well as have drag and drop in your views.
There are several training and example videos here: http://rhomobile.com/webinars/
I'm about to begin development of an iPhone app. The app itself is fairly basic, and I want a speedy turnaround time.
I'm a web developer myself, specialising in traditional web technologies such as PHP/MySQL; I have no experience in Objective-C.
My plan was to create a very basic iPhone app that is just a Safari service that passes some basic variables to a URL. That URL is the app built in PHP and housed on my servers, this way I can create the app very quickly without needing to outsource anything.
My question is whether apps of this nature would be accepted into the iTunes store, or would they be out-right rejected? Anyone's experiences or comments are very welcome.
Thanks
It could go either way, but mind bullet 12.3 from the App Store Review Guidelines:
12.3 Apps that are simply web clippings, content aggregators, or a collection of links, may be rejected
In my opinion, a simple UIWebView wrapper around your web site comes close to the definition of a simple web clipping. Your approval may very well hinge on your luck in drawing a sympathetic reviewer.
It really depends upon your application...These kinds of application have been approved in the past but again I am saying that it depends on many factors.
Try to test your app in every possible manner and also keep in mind the memory issues.
Best of luck!!!
Should be fine - its called a web app and there is software out there that will do just this for you.
All you need to do is to make a UIWebView and put your web app into it.
Also look at http://jqtouch.com. That gives you some idea of what you can do web-side. :)
http://www.netbiscuits.com/559
Native Hybrid Apps
Native apps can interface more deeply
with the mobile handset modules and
sensors to create an even richer
mobile user experience. Netbiscuits
provides pre-build native apps
frameworks for all major mobile
operating systems to be easily
customized for the needs of
enterprises.
Get "2in1" by combining the power of
mobile websites and native apps by
wrapping mobile websites into hybrid
apps and list them easily in all major
app stores of providers like Apple,
Nokia, Google or Samsung to open a new
mobile distribution channel. The
benefits of this approach are fast
time to market, minimized development
and maintenance efforts and maximum
mobile cross-platform technology
coverage.
Yes, it will be accepted as long as you stick with HTML, CSS, JS and Obj-C on the client side. You still need to wrap it in an iPhone app. In my experience, the best way to this is to use http://www.phonegap.com/ or a similar framework.
You'll have the option of deploying you app through iTunes or as a regular web app (you users will be able to create a link to your web app right on their springboards)
It SHOULD be accepted, granted you test test test and make it look just like a native application. Also you'll have to make sure that your server is never down, or if the application can't reach it just display an error message. You also have to keep in mind that there are a lot of iPod Touch users, and they don't have access to the internet all the time. Which means that chances are you'll get a BUNCH of 1 star reviews
Although not really a programming question I believe many developers would have come across this and therefore give the best answer.
Currently I am developing an App for iPhone for the organisation I work for. Its close to release and there is heaps of interest when I present it but the occasional question comes up am I going to port it to Android. My answer is I would like to but according to web stats more than 90% of phones hitting our website are iPhones and the other 10% is declining (probably people migrating away from Blackberry, last count was 98% was iOS)
Now if you read the media many people would like you to believe that its a split market between Android and iPhone but this might be just in the U.S where the single carrier for the iPhone has limited its consumer uptake because all the information available to us (at least in my organisation) states otherwise.
I was curious to hear from other people who have looked into these stats both inside and outside the U.S because when I tell the person asking that there is no demand they dismiss it and say its growing, once again contradicting the stats available for our organisation.
I am really interested in Android dev so don't really want to hear that I should just make it to give people an alternative, it's hard to justify to management that I should spend their money to deliver content to 5% of our market. Currently it makes more sense to make a cut down web App rather than an Android App.
Be interested to hear your thoughts. Cheers
Honestly, I would argue it simply depends on your market. For instance, in my location Android users are increasing steadily. It still took us a long time to commit resources for development. Plain and simple, until recently, there wasn't enough return value to develop an Android app. If your Android market is only a small percentage of your market, then the resources would probably better be spent within your main competencies (i.e. for my company, developing more iPhone apps). It is easier to make a presence for a new app or upgrade in a market you are already established in. After creating the Android app, you would need to spend more resources on creating brand awareness, which if you already have a successful iPhone app, wouldn't be necessary if you simply created more iPhone apps. Also, let's be honest, the Android marketplace is a bit of a mess and hard to market on. Don't get me wrong, I have a healthy respect for Android and its capabilities, but unless you can see a return on the app, there is no point in developing it.
Depending on the type of application you are developing, it might be worthwhile to utilize a mobile framework that allows you to easily develop for both devices (plus many others). This is not the solution for all applications, such as those where speed is critical or games, but for many apps it might help. Have you looked at Appcelerator or PhoneGap? Just be careful to do plenty of research and make sure they support all of your requirements before jumping in.
It's difficult to answer your main question because the statistics related to mobile devices varies immensely, especially related to the type of application you are developing. Certain types of users prefer one type of phone and those users typically will use only certain features. For example, BlackBerry users are less likely to download games than iOS users.
For web apps
The approach suggested above is a nice approach because phonegap, appaccelerator or rhomobile do provide a sort of a virtual environment for applications developed in HTML, ruby. However, that might not be sufficient in a number of cases.
One of the approach i have seen developers adopt a lot for native apps
If you have developed your application using C code for the application state machine and lower levels then that code can be ported straight away to Android and be plugged into Android app using JNI technology.
The UI will have to be re-created.
What is the value to your organization of that 5% of customers being able to have a native Android app, versus the company's development time/resource cost?
Now that you've done all the app architecture and design work (including artwork, documentation, etc.) for the iPhone app, will a porting or rewrite for Java/JNI/Android take less development time by some multiple?
I think the most important factor is that if your company have the resources to maintain two version of the app. Would it be more beneficial to maintain native iOS app and a mobile version of the site? Since as you mentioned the usage of non-iOS devices of you website, as a metric lead a conclusion of such already.
As a matter of fact, if you have put most of the logic to the server back-end, writing an android app would not take anywhere longer than writing an iOS app, as long as you've programming experience in Java.
Also contrary to common beliefs, since the market share of Android phones are not as good in your place (would you mind telling us where your company is resided in?, it would in natural have less localized app in your geographical location. So creating an app specifically for them would gain more acceptance. That is fact, is a good thing. (see: Long Tail theory)
I've talked to a lot of people recently who say they are expecting to stop writing native mobile apps and start writing web apps once HTML5 gets more fully baked in mobile OSs. I just finished my first HTML5 deep dive, and I'm not yet convinced.
Will HTML5 work as a replacement development platform for native apps, or are there certain things that require targeting the native runtime?
HTML 5 is not magic. it adds a lot of long awaited functionality to HTML and to traditional web applications, but still - many things are still out of it's scope.
for example:
accessing your contact list
getting bluetooth data
making use of an OS specific function
for those (and other) functions - you would still need to write vendor specific applications.
One thing which necessitates the native app is the access to more features on particular mobile devices; it's not guaranteed that that all the features of the device is exposed via javascript interfaces to HTML5. In that case, you are forced to use whatever native APIs available.
In short, no. HTML5 provides an appropriate toolset for a large range of applications, so I see it growing popular in this arena (for portability reasons). I except there will always be application developers (and users) that prefer the native look and feel though, and there will always be scenarios in which bare-metal coding is required, or a 3D engine is more practical to utilize using system level API's.
HTML5 is a compelling technology stack though, especially when coupled with some cross-platform API management (e.g., PhoneGap).
Native applications will continue be able to use new device features first, before they are eventually supported up through to the browser so for cutting edge development, native will still be the way to go.
There is also an issue with discovery - right now users are accustomed to using apps and can find them in their devices app store. Searching for a web app seems unnatural to a typical user and that wont change any time soon. That's why a lot of apps that would seem to make more sense as a web app are still being produced as native apps.
Conclusion: Native apps will continue to be necessary, but mobile web app development will grow and may well replace more native app development as time goes on.
It will make some native apps unnecessary but not all of them. Not really much more to say about it :)