Related
Titanium claims it can do the same app on average 70% faster than native XCode.
What's been everyone else's experience in terms of difference in speed of development （between native XCode and PhoneGap or titanium) ?
Let's say an app like Kik Messenger or Badoo ....
Typically, a good XCode developer can do it in 4-5 weeks, assuming graphics and backend are in place.
What would it take for an experienced Titanium (HTML5) person to achieve this? (roughly)
Time to market depends on quality of specifications, process and people, much more than the underlying technology or framework.
Coding a real application with Appcelerator Titanium is not that easy, and runtime performances are SLOWER than native code because it's using a javascript engine as a bridge. Especially with a big TableView, it's much more slower, and the feeling is just not the same. But once you have purged the memory leaks, the feeling is nevertheless incredibly better than with HTML5.
You should be interested in Titanium or PhoneGap(now known as Cordova) if you plan to distribute your application on other devices or if you really don't like Objective C.
If not, keep it with the Native Xcode.
I would add that Cordova will not make any UI, but let you access camera, accelerometer or GPS with javascript inside HTML5 code. You would probably use Sencha Touch or jqueryMobile with Cordova.
In my experience, if the app is not a simple template app then you would be better advised to create a native app for each platform.
As Rob says, trying to overcome the lowest-common denominator situation and overcoming limitations in cross-platform "solutions" usually means it takes longer to code than doing it natively in the first place.
You might even hit a problem which causes you to abandon ship and start from scratch as native apps. So if you decide to go a PhoneGap or Titanium route then make sure you research fully before starting and that you won't have future requirements not covered by them.
If you are an iOS developer and you are developing it only for iOS device, then it is better to code using XCode. If you are more into Javascript and developing for both android and iOS then you should use Titanium or Phonegap. Between Titanium and Phonegap, I found it easier to code using Titanium(and yes fast as well). But I am not sure how much worth is using Titanium. http://usingimho.wordpress.com/2011/06/14/why-you-should-stay-away-from-appcelerators-titanium/
I'm actually performing a fairly intensive survey of all the major cross-platform mobile development kits right now. I started by making a sample application from scratch in IOS that uses a few simple device features, and then reimplemented that as an Adroid app. Both of those took about a day to complete (the android took maybe half a day longer). Since I've never written an android app before, I think that's a good baseline in terms of comparing development time between the various other frameworks I'm testing out.
I'll update this comment in a few weeks with a blog post when I'm done, but for the moment I've been finding that these cross-platform kits are vastly more difficult to use and take a lot more time, even for the simplest applications. and despite this, there's still quite a bit of custom per-device code that has to be written for UI and fundamental idiosyncratic differences between how device services function, so you don't really get the value of a true "single code base" that you may have been expecting.
I think the main value in these may turn out not to be anything related to development time or code reuse, but instead only as a way for non-app-developers to create simple prototypes that can later be handed over to the "real" mobile developers to be built out into true native apps afterwards... Not really all that useful in my opinion, but maybe my thoughts will change as I delve into this further.
Appcelerator is not HTML5, it is a native app built in a higher level language of JavaScript. It abstracts the complexity of common elements away and provides huge value, ping me offline to know more. I run our California business.
I'm about to develop an app for iPhone, Android, and for web too. I think there must be some "standard" way for doing this, in order to reuse as much code as possible.
Which is the best way for doing that? Webservices? (only if the app uses internet) Maybe an API? Another way?
Just for the record, the web application will probably be developed in Ruby On Rails 3.
Thanks!
There are a few cross platform development tools out there that let you write once and compile for multiple platforms. I know I've seen questions on both tool here on SO, so others might have some good advice on these specific products.
PhoneGap
http://www.phonegap.com/
Appcelerator
http://www.appcelerator.com/
Barring that, if you are looking at doing native development on each platform, the web services APIs are a good way to go. I've built an App that is heavily data driven, and I built out RESTful services over JSON that do the heavy lifting for the iPhone, Android and Web versions.
There still is quite a bit of work that goes into implementing a feature on each platform, but once I architect code on one platform the hard, creative work is done and it's just porting it to the next platform (Same applies, mostly, to the graphics as well). Since I am coding for each platform individually I do try to take advantage of both code and UI conventions for that platform to give the user a native experience (say building menus for the menu button on Android, something not supported on iPhone). To me that's a benefit of developing for each platform individually, however, it also greatly increases time to market for each version.
Since you're looking at Objective-C, Java and Ruby, 3 completely different languages, there's not an easy way to develop a shared library without using a intermediary layer like those linked above.
Well, all three are different languages, so anything you write for one won't work for the other. An API on a server may be able to get you the same data to all, but its highly unlikely that you'll get any reusable code. I'm doing the same thing, and realize that, so I am just sharing common things such as UI and code-design between them.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I want to build a mobile/tablet application whose core feature will be taking pictures with the camera , viewing pictures and receiving notifications. Also I want to target iphone, ipad and android platforms.
Titanium appcelerator piqued my interest because of its cross platform appeal. However I am concerned because I've read mixed reviews on SO and other sites. The things that worry me are:
Subpar android support
Camera support not fully capable (e.g ios 4.1 HDR capability)
Camera support buggy
The nightmare scenario for me would be to invest time in titanium only to discover later on that its a major PITA and drop it and go "native"
Please share your thoughts and experiences.
I chose Titanium for a serious application, although one that does not use the camera. I think there are a variety of things that could play into your decision...
If your app intends to do "fancy" stuff with the camera, or some real heavy image processing and so on, you're likely better off going native. If on the other hand, you just want to have it take pictures, and then those will be used as-is, or sent to a server, or what not, then Titanium should work just fine. Titanium does have some processing and image manipulation things, but as others have said, if you really want to take advantage of the device's hardware, you probably want to go full native.
It should also be noted, and Appcelerator says this as well, that with a Titanium app, you won't just write a single app that works as-is on all devices. You will need to taylor the UI to each device (or class of device, i.e. iPhone, Android), because they have different UI's, and different standard UI flows and so on.
But, one of the potential advantages to Titanium is if you don't know Objective-C and/or Java, and you do know JavaScript (and in my case, I'm actually using Coffeescript :). Or, if you would enjoy your work much more writing JS than ObjC/Java. This was one of the main reasons for me. I have done some ObjC dev in the past, and don't even mind it, but this project I'm doing is on a very very aggressive schedule, and it was just going to be far more effective for me to use Titanium. I was able to get set up and build an app extremely quickly, and I am not spending any time having to become more deeply familiar with the programming language I'm using, memory management bits (you can't fully ignore this with Titanium, but essentially they're doing it for you). Based on the folks I've talked to, and how much time they spend with memory management, Interface Builder issues (this is mostly the ease of forgetting to setup connections or hook various things up, IB is actually a pretty great tool), and so on, I'm quite glad I'm using Titanium.
While I expect to do an Android version at some point, it's not a priority. But, I'm glad to know that a large chunk of my app code will be re-usable, tested, etc. and that I'll wind up mostly just building/revamping the UI for Android, not rewriting networking code, data management, and so on. Android support will be much better (supposedly) in Titanium 1.5, but you may want to wait for that release to evaluate Android if that's a priority.
Finally, Titanium does have a "module" system, that allows you to wrap native code, exposing it as a JavaScript interface in Titanium. We are about to leverage this to integrate a third party library, and at least for what we need, it looks very easy to use, and has given me a little more confidence that if some particular native feature we need access to comes up, that we'd have a decent chance of integrating that while still using Titanium, but I think it would depend on what the particular native functionality was.
Good luck and enjoy building a mobile app, it's pretty fun!
We have been using Titanium in one of our projects for around 2 months, and frankly speaking our experience with Titanium is too bad.
As per my opinion, below are some major drawbacks of Titanium:
1) First thing is you will not get debugging support at all (We can understand how debugging require in any of the project and in any of the technologies).
2) Titanium is NOT fully supporting all the features of Android/iPhone; beyond some level it will not give you support.
3) Comparing with Android/iPhone SDK, developers will get very less amount of help from the internet and API library (Titanium provides the API library help file).
These are the general issues that end developers face while dealing with Titanium and I suppose sometimes it will be tedious and frustrating work for them.
If the functionality of your application is somewhat like displaying data from the web (like many news, media type apps) then Titanium is the suitable option; otherwise not.
The Android support is not near as good as it is for the iPhone. If you were to just say iPhone I would say you would have luck using Titanium. However, I think trying to build one code base in Appcelerator and also use in your Android environment may not be the best experience.
That said, IMO doing Android / Java code is much easier than doing Objective C / iPhone work.
So worst case I would consider using Titanium for your iPhone version & do Android in Java.
You can give it a shot doing them both in Titanium, but worst case code the Java version.
I just hate objective C and the 'native' Apple development environment so much.
I would recommend against using a cross-platform toolkit when interacting with device hardware is one of the key requirements of your application. I haven't worked with Titanium before, but I find it hard to believe that they will give you the same level of hardware access that you get with native frameworks.
In particular, iOS 4.0 added a mess of new capabilities regarding the camera, including live video frame processing through AVFoundation, and I find it hard to believe that a third-party framework will keep up as these platforms advance. To be honest, it's pretty easy to write an application that interacts with the camera on the iPhone nowadays (count the number of them on the App Store as an indicator of this). I wrote a live camera frame processing application in about six hours the other day.
I can't speak for Android, but I imagine dealing with cameras is fairly trivial using the native APIs there as well.
You're also going to find performance testing and debugging your application to be far easier using the native tools than those supplied through a third party. In particular, Apple's Instruments is an extremely powerful, yet easy to work with, application for tracking down CPU and memory issues within your application.
There's also the community aspect. You'll find far, far more people working on Android and Cocoa Touch than on Titanium (just look at the numbers of questions in the various tags on Stack Overflow to see that). This means many more tutorials and a whole lot more sample code that you can use.
The time you'll spend getting your iPhone and Android build environments set up, and submitting to both stores, will be the same no matter if you go with a native environment or with Titanium.
In the end, even with learning both platforms, I think you'll come out ahead by avoiding a cross-platform solution. Trust me, I've tried to do cross-platform development before for other projects and ended up with lowest-common-denominator products that took much longer to write.
I've developed an Appcelerator-based camera application and was very pleased with it. I think some of the negative reviews come from the fact that it's a bit hard to get set up (more due to Apple's crazy developer registration process).
Once I got started, it was easy to do things like overlays on top of the camera screen. I was really expecting difficulty with that part, but it worked well.
I have spoken with the Appcelerator team in the past, and they are a great group to work with. I've seen them be responsive to other user issues, and I'd trust that if I ran across a real bug, they would address it quickly.
A little late, but my two cents...
I honestly believe you can very quickly prototype an application with Titanium Appcelerator and focus on the critical feature sets to determine if it is the appropriate tool for you.
All developers have there opinions and experience(s) which influence there comments; developers have different ways of learning and different levels of productivity... In the end, it comes down to how are you most productive with the tools available to you.
Since you are stating from the start that you want to deliver a solution an multiple platforms, I think it would be a poor decision on your part to not even spend a week or two investigating cross-platform frameworks and then making the decision based on your personal experience.
There is Titanium Appcelerator and there is also PhoneGap, where PhoneGap might help you is that there is the ability to extend/enhance the underlying framework through writing plugins (I wrote one for iphone ) and there is an android one on my blog also... this can fill missing gaps for you when you move across platforms.
Also since the UI in a phone gap solution is HTML5 Webkit based, it can give you a consistent look and feel across you devices if you like. Frameworks like jQTouch and JQuery Mobile are being used for UX with PhoneGap Application
I reviewed negative feedback for Titanium Appcelerator but I tottaly agree with Aaron Saunders that if you use PhongeGap Development is support HTML5 which can getting easy to make apps for iPhone, iPad and Android mobile.
Has anyone highlighted the cost off titanium.
I was contacted by them today and if you are more than a one man band you have to sign up for a partnership program else you are held liable for breech of contract if you release the app.
The partnership program is £5000 which is far to much for us as a start up company when it's our first application, we are currently looking for a different option now.
Is there any MacOS virtual machine that can run on PC?
Is there any source to get it?
What is the best way to develop apps for iphone?
Yes all the developer tools are OSX only.
There are lots of iPhone development books out there go check out amazon and find one with some good reviews and that will get you started.
You might not, in the strictest terms, have to get a Mac to develop for iPhone; but it will be extremely helpful. Apple is relatively talented at squashing efforts directed towards Hackintoshes and virtual machines running OS X.
The shortest answer that will give you the least hassle is: Yes you need a Mac.
But, as far as I know there are a few possibilites, that try to reimplement some Cocoa Frameworks (however they might be Mac OS X only and not iPhone): GNUStep is an example.
But I don't think you get something aquivalent to Xcode (the IDE for iPhone development) this way.
And I think there are some OSX86 Virtual Machines (however these seem to be against Apple's EULA and thus seem to be clearly illegal so I won't point you anywhere to get them).
So to conclude - if you want to develop for iPhone: getting a Mac is the easiest way, even though not cheap.
Hope this helps.
The short answer is - yes.
One possibility for learning some of what you need to know before getting a Mac is GNUstep.
However, GNUstep is mainly useful for learning Objective C, especially since it provides many of the classes that the Cocoa toolkit for iPhone does. This can be run on Windows.
It doesn't, however, support some of the key 2.0 language features that are used 'all the time' in any sample code.
What it will allow you to do is design a UI using their UI designer GORM, and use a near-identical message-based system for implementing a UI, and you could theoretically write Objective C classes in GNUstep and then use them on iPhone.
However, to compile an app for iPhone you basically need to have a Mac, because then you can get the key for signing an app, etc. Since you need to get a Mac at some point, there's really little point in going the much harder route of using GNUstep first and learning a more limited implementation, unless you really need to get started before funds are available.
Despite the new SDK terms that can other programming languages, if you're really wanting to start without a Mac, I'd probably be tempted to look at something like Unity, or perhaps even Appcelerator Titanium, and figuring out all the non-platform-specific logic first on whatever platform (Unity has a free version that can be run on Windows, for example).
I'm not that big a fan of xcode, but is is far and a way the best IDE for Objective C development simply because there's almost nothing else out there.
There are, as always, other options. If you do a web app type project, you can implement the website and test a lot of it in a browser. Furthermore, since Android and iPhone browsers are both WebKit based, you can use the free Android SDK to see what pages look like on a comparable mobile device. And since you can use C and C++ classes as well as Objective C (N.B. not for the GUI, since that needs the Objective C extensions for messaging between objects), another option for making a start without a Mac would be to use Eclipse, QT Creator or some other C/C++ IDE to implement non-GUI classes, so long as you make sure you don't use platform-specific libraries.
But the end of the long answer is still that whatever you do, to compile a proper iPhone app you'll be using xcode and associated tools to finally build it and sign it, and so you need a Mac in the end. If you want to create something targetting the iPhone and won't have access to a Mac, then perhaps you're best off looking at creating an iPhone-adapted website using iui or a similar toolkit to give the site a suitable look and feel.
As a .NET developer, I always dreamed for the possibility to develop with my existing skills (C#) applications for the iPhone.
Both programs require a Mac and the iPhone SDK installed.
Appcelerator Titanium was the first app I tried, and it is based on exposing some iPhone native api to javascript so that they can be called using that language.
Monotouch starts at $399 for being able to deploy on the iPhone and not on the iPhone simulator while Titanium is free.
Monotouch (Monodevelop) has an IDE that is currently missing in Titanium (but you can use any editor like Textmate, Aptana...)
I think both program generate at the end a native precompiled app (also if I am not sure about the size of the final app on the iPhone as I think the .NET framework calls are prelilnked at compilation time in Monotouch).
I am also not sure about the full coverage of all the iPhone API and features.
Titanium has also the advantage to enable Android app development but as a C# developer I still find Monotouch experience more like the Visual Studio one.
Which one would you choose and what are your experiences on Monotouch and Titanium?
Like any which-tool-or-platform-or-language-or-framework-or-whatever question, it should really come down to what you want.
Forget all the if-you-want-to-develop-for-this-platform-then-you-have-to-pay-your-dues advice. If you're interested in learning Objective-C, Xcode, and associated Apple bits, then go for it. I did. It's been fun, but my interest was in developing iPhone apps. Learning a new language, framework, and IDE was just a bonus (I like this stuff). It was also necessary when I started.
I've been working with MonoTouch since it was released, and I love it. I prefer C# to Objective-C, and I like having access to the subset of the .Net (Mono) framework that MonoTouch provides. There are certain things that are simply easier to do with .Net than Cocoa (string manipulation, date manipulation, anything XML, etc.).
I also like not having to deal with reference-counting anymore. I was spoiled by years of not having to keep track of resources at that level. I don't mind having to clean up after myself, but I don't want to have to manually do something that every other modern dev platform I've used does for me automatically. Plus, even for seasoned Objective-C devs, reference-counting isn't a no-brainer. Scroll through OS X's console output sometime to see how many apps crash due to memory-management issues (I know - this can happen with basically any app, but it's far easier to make the mistakes that lead to this situation when you get overworked devs involved whose attention spans have been destroyed by twelve hours of if this and if that and else this and else that and blah blah blah).
I still use Objective-C/Xcode - I've really learned to like Apple's tools. I honestly feel they're awkward and a bit arcane, but still fun.
But... then I also like this:
public string SomeString { get; set; }
To do the same thing with Objective-C (on the iPhone, anyway) requires that you declare a local variable to back the property, write the property declaration, and then use the "synthesize" directive to have the property generated for you (depending on what property attributes you specify, you might have a property that wraps getters and setters that take care of reference-counting for you - overall, this is a time-saver, but the C# Way is the clear winner here).
That's just one example of how MonoTouch can make your life easier, especially if you're used to .Net/Java/Python/other languages that don't require that you get your fingers dirty with memory-mangement (unless you want to).
As far as iPhone-ness is concerned, aside from brining part of .Net to the iPhone world, the MonoTouch namespace maps to CocoaTouch, so if you're confused about, say, the MonoTouch UIViewController, you can just hop over to Apple's docs on the UIViewController. MonoTouch .Net-izes CocoaTouch, but it's close enough that you're unlikely to hit a wall (that wouldn't have also hit if you were using Xcode/Objective-C). It's slick.
Titanium is different. Since they're trying (trying) to create an abstraction layer that lets you write the same app for multiple platforms, you're going to deal with the usual drawbacks: Totally different APIs, loss of flexibility (the same could be said of MonoTouch, but not remotely to the same degree), and basically having to learn a whole new platform (which is what you're trying to avoid by getting around Xcode/Objective-C/CocoaTouch, right?).
I also hate JavaScript, so I'm going to be biased against Titanium. But even if that weren't the case - even if I could use a language I do like - the APIs don't tickle my fancy. Or my anything.
Regardless of the dev tools you choose, you will end up having to learn something about CocoaTouch. Whether it's Xcode/Objective-C, MonoTouch, or Titanium, something is going to break or go all wonky on you, and you're eventually going to have to refer to CocoaTouch documentation.
If I were giving a talk on iPhone development (which I have, and which I will be doing again), and if I were to discuss alternatives to Apple's dev tools (which I will), I would still strongly encourage devs to at least work through a few basic iPhone apps using the native tools. It's going to make you a better developer for the platform - period. And you can use this beginning phase to determine if you even want to use anything other than the free Apple-supplied bits. You might not. I've been using MonoTouch because it pleases me - not because it's necessary.
So, to summarize a few basic criteria:
Preference (language/frameworks)
Devices (do you care about non-iPhone platforms or think you might someday?)
Comfort (if you like and know C# MUCH better than Objective-C, there's no reason not to go with MonoTouch)
And don't listen to the naysayers unless they've actually used the tech they're talking about. For example, I've read about Titanium, but I'm not experienced with it - I just know that I don't want anything to do with it on account of my preferences. That doesn't make it "bad" - just something I don't want in my life.
The Objective-C crowd can be impressively zealous. While there are plenty of open-minded devs in it, there are so, so, so many who think Objective-C and Cocoa and blah blah blah are THE last dev tools devkind will ever need.
Ignore them.
If you're worried about support, here's some stuff to consider:
Apple is likely to remain current, as they're the ones making this junk.
MonoTouch is likely to remain current - the Mono peeps have done an amazing job keep up with Microsoft, and I see no reason why they won't do the same with Apple. I'm blown away by what they do. And despite MonoTouch having been released, like, five minutes ago, they already have an update out for iPhone 3.1 stuff. They're serious about this, and I think they're magic. They're the Keebler Elves of the dev world. They sit in their secret layers and crank out stuff everybody (ok - not everybody) likes, but that nobody else would even attempt to do.
Titanium is either going to become an awkward unified API for writing apps for multiple platforms that is entirely its own thing, or it's going to become more and more splintered as the capabilities of different platforms diverge. Yeah, that's a bunch of typical armchair nerdly future-gazing... I should have prefaced this bullet item with "It's my opinion that..." If only there were a way to go back and change it.
Go with what you like. MonoTouch is a "safe" alternative to Apple's stuff. I'm afraid Titanium is going to go down the same old oops-this-super-high-level-platform-abstraction-layer-stuff-doesn't-really-work road that so many other technologies have. But if you're doing something simple, there's no harm in giving it a shot, especially considering that it's free during the beta period.
These are fun and interesting ways you can build iPhone apps. But, for truly rapid native iPhone development, your best bet is the free iPhone SDK and Xcode.
To be honest, the hardest things to learn are the capabilities of the frameworks themselves, NOT the language syntax. But that is an issue you have to tackle either way as these IDEs/Languages still require you to grasp some of the conventions of Cocoa (and Cocoa Touch).
I don't say this as a Cocoa / Objective-C snob, but if you know C (which as a C# dev you do) there really isn't any barrier to entry.
In addition, you will have access to tons of tutorials and sample code that just won't be available for these fledgling translators/IDEs/languages.
Learning another programming language is rarely a bad thing, and as an experienced programmer, your time investment won't be as large as you think.
I've created an open source project http://propertycross.com that helps developers select a cross-platform mobile framework by showing the same application implemented with Sencha, Titanium, Xamarin and more. This project allows you to easily compare a wide range of frameworks in terms of end-user experience, code, IDE, developer experience etc ...
I kinda like the idea of providing means to quickly get a grip on iPhone dev with techno people already know.
I personnaly, as a Java developer, use iSPectrum (http://www.flexycore.com). It also come with an IDE, debugger and stuff, which make it really convenient to develop with because it benefits of all the power of Eclipse Java plugin.
Being based on Java, this also allows to easily reuse already existing code from other java apps, which can be really handy providing that Java is present on almost all platforms (desktop & mobile alike) except iPhone.
Plus it's free for open source projects.
I'd rather consider these kind of solutions, because I don't like the idea of coming back to developing in emacs :) .
I know this is an old topic, but in the interest of staying current, it looks like MonoTouch and other cross-platform frameworks are going to be banned in SDK 4.0. Your only "safe" bet for writing iPhone apps is to use XCode and Objective-C, at least for the time being.
If you're C# programmer why you shouldn't invest some times to learn Objective C. Honestly speaking, it will not take much time from you. But you feels good to work in a new platform with new language. Learning new things all time fascinates me.
There are numerous ways to get on the device. Apple has stated in the SDK license that the only approved way to get on the device is via C, C++, ObjectiveC, and Javascript.
It appears at this point in time that apps built on MonoTouch and Appcelerator Titanium are being accepted into the App Store. Thanks to the license change, there is much fear, uncertainty and doubt on this subject. Apple has scared everyone not doing ObjectiveC.
I would suggest that you do whatever makes the most sense for you as a developer. If you know C# and .NET, you should go with MonoTouch. If you know ObjectiveC or the Mac platform, ObjectiveC is probably the way to go. If you know X and it's on the iPhone, well, X is where I would suggest looking first.