I am developing an application which is kind of similar to Skype with some more features. I am amused and surprised by Skype's response to various mobile platforms i.e. iPhone, Android, BlackBerry, Symbian, Bada OS etc.
I want to know how Skype is able to so rapidly release versions for iPhone, Android and Blackberry?
Do they write code targeting every platform separately or do they write code once and then use some utility to make it available across all platforms?
As a developer I am kind of curious to know the real technique which can be the reason of behind the scene magic. Any clues?
Answers with valid sources and references are more appreciated.
They are an $800 million/year revenue company, its probably not a huge deal to support many platforms.
From Quora : http://www.quora.com/Skype/What-programming-language-was-Skype-originally-written-in
The original internal alpha version of UI was built in QT and we hoped
to do few platforms at same take. However the result looked like crap,
our progress seemed slow and we ditched the QT about 2 months before
public beta release.
Delphi was chosen because our first senior UI developer was very
skilled at Delphi (besides dozen other languages-environments) and we
saw D as most productive, fastest, efficient way to build our app
given our team/lead developer skills and also getting very good UX on
MSWin platform.
For linux the QT remained and on OSX it has been Cocoa from the start.
The functional core components which did the heavy lifting under the
UI have always been the same C/C++ as Ahti pointed out.
They developed different versions for every platform. There is no single language that supports all platforms, unfortunately. If there was, it'd still be a hassle because every platform his it's own platform API.
Related
I hope this question is specific enough. I have a client for whom I made an iOS native app and an Android native app (same app, different platform). It's a fixed pixel design (I made this work for Android somehow:) and it works on iPad, iPhone and most Android devices (with some letterboxing). Now I am asked to write the same app for the Windows store and they want me to use HTML and JavaScript. My question is, when I use HTML and JavaScript, would it be "easy" for me to use this code into some sort of hybrid solution (PhoneGap, etc)? The app doesn't need much complicated functionality but does need to support push notifications on iOS and it needs to be able to play videos, preferably HLS. Any advice on what the best hybrid solution and do hybrid solutions allow you to build for Windows 8?
I'm a cross-platform developer working on PhoneGap and Titanium Appcelerator. The correct answer is "It depends". Currently the state of cross-platform development is not very recommendable. Yes, you can write plugins for PhoneGap and it does support windows phone but you will have a ridiculously hard time getting them to communicate with each other properly. I learnt this from experience.
If it was a hacking/hobby project to further the cause then I would say go for it but for a time-bound client project like yours, I would recommend against cross-platform solutions and go native instead. Plus native always gives considerably better control, speed and ease of development. You will probably develop it faster in native than cross platform anyway. I've played around with windows SDK and it seems easy to use and well-built with good documentation and you can use C# which is similar to Java since you have already used it on android.
You can also build windows 8 desktop apps using html and javascript natively but this isn't present in windows phone 8 yet.
As I mentioned, If you don't need too many native controls, then you can go cross-platform. For your requirements, it can be done. If you have already developed android and ios apps and only need windows app now, then going native would be easier. But if you have to make all 3 then you can go cross platform if your requirements are restricted to what you mention. Here's a good quora thread that discusses the pro's and cons:
http://www.quora.com/Is-Titanium-good-for-developing-iPhone-apps
Take a look on Xamarin
Main idea - they brings real native code for all platforms.
They have instruments to compile C# code that it can be used at all platforms
For example you should create UI in XCode (for iPhone) and use ModoDevelop to create DAL/BLL, then you can re-use C# code base over all other platforms
They have cross-platform iPhone/Android/WP7/W8 samples on GitHub
Also see Q&A on Stackoverflow tagged Xamaring
We are starting to build multiple apps for multiple clients both in IOS and Android native platforms. The problem is we are going completely native which is taking too much time.
I would like to look at the linked in method (http://arstechnica.com/information-technology/2012/10/a-behind-the-scenes-look-at-linkedins-mobile-engineering/) which is a more hybrid approach using HTML and native code.
The problem is I don't think Phonegap is that good - good for prototyping but maybe not for full versions of apps as it can be a bit slow and a bit buggy.
I would like to look into doing a model where we create like 65% HTML and 35% native to that device (like linked in)
Would anyone have any suggestions for this? Would people say we need a massive development team to pull such an approach off?
I welcome thought:)
Thanks
We will develop a, social network integrated mobile application which will need to access native device capabilities but 90% of the logic will be implemented in the HTML5/Javascript code posted by Ruby back end to the device. Thus, we would like to update or change the logic/GUI of the app without user involvement. We have strict deadline and have to support iOS, Android and Blackberry.
In this case, what approach would you recommend us? We considered the approaches below but could not decide since we do not have any experience with mobile development even if we are experienced in Ruby, C/C++, Java, Javascript, Flex.
Our considerations:
Develop native apps for each platform and embed the native browsers
to implement our logic, which can take too much time.
Use one of the frameworks for cross-platform development such as
PhoneGap or rhomobile. In this case, we are afraid of facing some performance issues. We would love to hear the experience of developers with those frameworks.
Use Adobe Air for accessing the device and its WebKit component for the rest.
First, I hope you understand that there is no simple answer. At this junction, having been looking at cross-platform solutions for mobile development for two years, I feel that in order to get fully native UI look, and to access all the device and UI features, one is forced to produce native application on each platform.
But, since you asked about cross-platform tools, here's a list of the main contenders:
Sencha http://www.sencha.com/products/touch “Sencha Touch is the world's first app framework built specifically to leverage HTML5, CSS3, and Javascript”
Dojo http://dojotoolkit.org “Dojo saves you time, delivers powerful performance, and scales with your development process”
Phonegap http://www.phonegap.com “PhoneGap is an open source implementation of open standards”
jQuery Mobile http://jquerymobile.com “Touch-Optimized Web Framework for Smartphones & Tablets A unified user interface system across all popular mobile device platforms”
Rhomobile http://rhomobile.com “Free and open source mobile application framework”
Titanium from Appcelerator http://www.appcelerator.com
There are plenty of comparisons online, including on SO, and this fellow actually tried to use several platforms, code included.
Anecdotally, I have seen Phonegap produce a rather iPhone-centric look, that may not mesh well with Android, plus showing performance problems when loading screens (there may be workarounds via pre-loading). Also, access to more complex devices was limited, or at least lagging. Rhomobile is a good fit for data-driven apps (simple display of large databases), but architecturally could show performance issues, so check for yourself. Personally I did not get into Sencha, Dojo seemed a little small, and Titanium showed dated architecture. So next time I'm attempting a cross-platform app, I'll give jQuery Mobile a serious try.
Let us know what you pick and how it works out.
Iam using this rhomobile rhodes for my cross-platform development App which will run in Android, Blackberry and iPhone.
We have developed application and sucessfully runned in all devices without any issues. we used ruby for backend webservice call, And remaining app is constructed with HTML5 and java Script. I didn't face any issues regarding rhomobile.
intially we faced memory issues, But later on we resolved this issue by implementing local storage for our App. For android it wont supports local storage so we used Rhom Storage only for Android Device.
Sounds like a project doomed to fail.
If I were you, I'd build a mobile-friendly site for all 3 platforms if deadline is tight. What native features do you even need, first off? If it's something like a camera, you're better off just build a native app for all 3.
I am going to develop an application which will be cross platform and it will be released for IOS and Android.
My App will be using network connectivity and communicate with the server and it has to be fast, reliable and responsive.
So my Question is: If i choose Adobe Flex to build that app for IOS and Android, So will there be any performance issues?
If no then why people use xcode or android sdk?
What are the disadvantages of using Adobe Flex over xCode and Andoid SDK?
Generally speaking, if you use a cross-platform "write it once and build for many platforms" tool you likely will give up the ability to take advantage of some (or all?) device- or platform-specific features. You are, in effect, choosing a lowest common denominator sort of solution. That is to say, you have available to you only the platform features available on ALL the platforms you are targeting.
Building a native app -- that is, using Xcode to build an iOS app and using the Android SDK to build an Android app -- gives you complete access to all of a given platform's specific features and capabilities, thereby ensuring the best user experience on each platform.
This is now my opinion: Native apps are better, simply because they present the user with a native experience -- an experience that will feel familiar to them as a user of the platform. When you choose to use a cross-platform tool you are actively choosing to give your user a less-than-ideal experience on their device, but YOU saved some time (maybe) getting your app to market. Who's the winner?
In my job, my boss and I had a specific conversation about this. We have native iOS and Android apps, on purpose, because we didn't want to give up platform-specific features. We wanted each app to give the best experience it could on its platform. We specifically agreed that a cross-platform solution was not the way we wanted to go.
Depending on what you are building, Air is a great platform for developing cross-platform mobile applications. Despite recent news that the Flash player is no longer being developed for mobile browsers, the native story remains strong. Plus, having seen native IOS, native Android and Flex development, the Flex platform is much better when it comes to the ease of development. With high-level features like data binding, visual state management, a solid component/skinning model, transitioning model, etc, it is a generation or two ahead of iOS and Android (IMO).
If you are using Flex for mobile (iOS/Android/Playbook), you get a common look/feel across all mobile devices. #MarkGranoff suggested that the user experience is downgraded when using an approach, but I'd challenge that.
Although I agree that an out-of-the-box styling of the UI components in Air feels a tad off, I don't recommend that anyone build apps that way anyways. Instead, create an app that looks like your app. There have been many applications that don't conform to the native look/feel of iOS or Android but are still quality from an aesthetic and UX perspective.
There is something to be said for an app that looks/behaves the same across all platforms. I can tell you this much... the user doesn't really care. If it looks good, feels good and does what they want, they are happy.
The Flex Mobile SDK uses a lot of the same UI paradigms (especially in the soon-to-be-released version of the SDK) and it is getting better. I wouldn't discredit it. You can save a lot of money and time using something like Flex Mobile.
You can use Flex to compile to AIR for iOS or android.
The performance of AIR vs Objective C or Java is significantly slower.
The advantage of using AIR is to have one cod base delivered to two platforms.
But if you have the know-how, Objective C and Java are better suited to development on their respective platforms. However many successful apps have been launched on iOS and Android using AIR. If you want to know if it would work for you I would seek out those apps in iTunes and Android Market and see how they perform for you.
If you app is not a game it will likely work fine. And if you app is a simple game it could also work fine.
Also remember there are other multi=platform development tools to choose from, like phone gap, or appcellerator:
http://www.appcelerator.com/
http://phonegap.com/
or even Unity 3D:
http://unity3d.com/
UPDATE:
Since this original answer in Novemer 2011, Adobe has made significant improvements to AIR for iOS and Android. Petformance problems are negligible unless you are doign somethign very instinsive such as large image processing.
Likewise, Unity3D has improved a lot too. It's an excellent choice for games that are 2D or 3D.
if you are using Air to develop cross platform apps, you should notice the following facts:
1) you don't have access to native features (but you can use Air Native Extensions to by pass this problem)
2) performance is slower than native apps (but you can use Starling framework to use GPU power in devices which will increases the performance a lot!)
the bottom line is that building mobile apps using AS3 and Flex/Air SDK is the best solution you can think of and the performance if using starling is much higher than native apps!
I don't think you can use Adobe Flex on iOS. Another cross platform solution to investigate would be HTML5. If you can afford it, the best solution might be to implement it twice, once with xcode for iOS and once with Android for Android.
I have been making applications in objective-c for a while now and feel i have a good understanding of it. I have made many applications and started to make a few basic games.
However now i want to target android as well. I recently saw applications such as Titanium and the Corona SDK that let you create applications in one language and deploy to both platforms.
My question is, for anyone experienced with these, would it be better to just learn how to code android applications and then make android and IOS apps separate, or would it be a much better idea to start using one of the development tools listed above?
I am mostly talking about the creation of standard applications, not games.
Also more importantly, if i was to apply for a job developing apps, what would the company look for? someone experienced in each platforms sdk respectively or someone familiar with the titanium or Corona sdk to code and output the applications simultaneously.
I have looked around but could only find info regarding people who have not started either android or iphone development. I am already very familiar with objective C and iphone development.
If anyone could help that would be great!
Thanks for your time!
I would suggest learning the native Java SDK. If you do anything more than simple apps, you will feel constricted and limited by the "write-once" SDKs, as you will want to exploit the special features of each platform.
In terms of employability, if you know both native iPhone and Android SDKs, I would expect your employability to be much higher than just knowing the cross-platform language. By having a diverse knowledge of "complex" languages (such as Java, and Objective-C), if employers wanted a cross-platform approach, they are likely to recognise your adaptability to the task at hand. Conversely, by only knowing cross-platform development, you are limiting your chance of work - if the client wants to use a more in-depth feature of the platform, which is not available in your cross-platform language.
Do you have any experience with java? If not that is where I'd suggest you start. And unfortunately there is no end all be all for what potential employers may be looking for. It would depend on specifically what they are aiming to have you create(Something that makes more specialized use of one of the platform features would likely require a native app. Where as something mostly based on content could use one of the phoneGap type solutions because it would result in farthest reach). I can tell you though any of the "write once - deploy everywhere" platforms that are currently available will limit the amount of platform APIs you'll get access to. Because of that I would personally suggest that you dig into the native platform some and once you have a decent understanding of how things fit together at a high level maybe start looking at the other solutions.
If you know Java, then my suggestion is to use native SDK for developing in Android. The OO concept is similar, but the design is somehow different from iPhone development.
Platform like Titanium may be good for standard apps. But I think gradually you will want to use and tweak the native libraraies functionality. Then common frameworks are weak.
I have been developing for iPhone, Android, JME, BlackBerry also tried HTML5, my understanding is to use the native platform if possible. But the app is small, e.g. a simple RSS reader, then common platform is okay.
But in most of the cases, developer want to use special features provided by the native SDKs.
If you want to stick to Objective C, checkout out Apportable, which enables you to build and deploy Objective C apps to Android.
At our company there is a huge push for cross-platform (iOS and Android) development. Appcelerator Titanium is being considered (and seems to be the only thing that's being considered) to achieve multi-platform development without extra development time.
Everyone here can think of reasons to use Titanium. For reasons against using Titanium I guess the performance of the resulting "native" app from Titanium may not be as good as an app written in Objective-C for iOS. How significant would the difference be? Are there other reasons to not use Titanium (or equivalent)?
Note: I may write Titanium but reasons may not only be Titanium specific only. All reasons in support for coding in platform language (e.g. Objective-C, Java) qualify.
The Good:
Can create iPhone apps using very simple Javascript.
The Bad:
Apple has been rejecting some Titanium apps due to private API calls but Appcelerator hasn't responded to requests for help, nor updated their SDK. http://developer.appcelerator.com/question/123785/app-has-bee-rejected-by-non-public-api
"Native Widgets" are used, but only nominally: there's a layer of
logic and abstraction between them and your code; and this layer
changes their behavior and reduces their speed. The difference is
visible in the Showcase apps.
API docs are perpetually out of date. (no process for refreshing).
A wiki was created, which is becoming out of date. Editing only
allowed for employees.
Github projects do not have wiki enabled.
Appcelerator isn't true open source: they do not accept contributions from the community: The
titanium_mobile project on github has a long list of open pull
requests.
The help forum software has many technical & design weaknesses.
Email notifications from the help forum often do not work.
Staff rarely answers questions in the Q&A forum. Haven't been seen
in months.
Showstoppers appear continuously in "all the little gaps":
Correctly displaying images on the iPhone 4
Correctly loading images in a scrolling list
Although the platform does simultaneously support iOS and android,
the library/framework does not. A lot of runtime testing (if/then's)
is needed in apps that will work on android and iphone.
Continually releasing new products but not fixing existing products
and website problems. The "new" products are announced while in beta
and release candidate phases.
"Chat with Sales" app not attended to.
Appcelerator does not take down outdated training videos.
Stretching the truth and bait-and-switch with pricing: a 30% sale
only applies to yearly memberships, not month-to-month. The blog
posts & marketing materials do not state this. Only upon checkout is
this shown.
[Seen 8/13/2011] Another way in which Q&A forums are broken: The order of
results for a search is trashed: each page of results orders its hits
from oldest to most recent, at the bottom of the page. Go to the next
page of results (i.e. 51-100), and again, the 1-year-old hits are
first, with 6-weeks-old at the bottom.
My Unanswered Questions:
[Seven unanswered Q&A questions not shown: I don't want to be personally identified by Appcelerator staff
and receive sub-par treatment.]
Results:
Am spending many hours trying to discover an API in the absence of documentation, and hacking to discover workarounds. This time is wasted, and would have been better spent simply learning to make apps in XCode & Objective-C.
How significant would the difference be?
AFAIK, Titanium will generate Objective C, so unless their stuff is woefully inefficient, I wouldn't expect speed to be a major issue.
Are there other reasons to not use Titanium (or equivalent)?
Well, that depends on how you define "equivalent".
Personally, when I get into cross-platform apps, I expect that I will use PhoneGap. That's for one reason: standards.
With PhoneGap, you're writing HTML, CSS, and JavaScript, as if you were writing an HTML5 offline app. All PhoneGap does is turn that into an installable package (e.g., APK for Android) and give you opt-in proprietary APIs for getting to device-specific stuff. Their expectation is to simply fill in the "gap" between what HTML5 on mobile supports and what native apps on mobile supports. Heck, it's even in their name. :-)
As a result, what you are writing is the same sort of tech you would use for a Web-based app, and it may even get to share some of the client-side code. You can use whatever you like from mobile frameworks (e.g., Sencha Touch, jQuery Mobile). And, if someday app stores support HTML5 offline apps, you might even be able to drop PhoneGap altogether, if you're not heavily dependent upon the device integration features.
Titanium lets you write in JavaScript, but the standards compliance largely ends there. You're using proprietary APIs for everything, including the whole UI. Personally, I'd rather back a more popular horse -- HTML5 in this case, more so than PhoneGap specifically. If for no other reason, it'll be way easier to hire HTML5-savvy developers than Titanium-savvy developers.
Neither PhoneGap, nor Titanium, nor any of the plethora of other options (e.g., Rhodes, Flash/AIR) give you all of the device capabilities. These engines will vary in their extensibility -- I know that PhoneGap has a plugin model, that Flash/AIR is pretty much only what you get from Adobe, and I'm not sure about any others.
Titanium has one advantage: you get a near-native UI, instead of an HTML-based UI. (I say "near-native" because some of their widgets do not necessarily have native equivalents on all platforms, so they roll their own as needed) For some apps and some audiences, that alone may tilt things in Titanium's favor.
Titanium/iOS specific answer, my 2c.
Native iOS vs Titanium
PROS
It's nearly as fast as native for most things.
The time needed to write a working prototype it's way shorter.
If you need to integrate javascript legacy code or libraries it will work provided that it doesn't use the dom.
Your javascript code needs to be well spaced and to include semicolumns where needed or the compiler will complain and eventually abort the build.
You can use Coffeescript or any other language that compiles to js
Automatic memory management is top notch, getting the same results in objc is always time consuming and sometimes debugging intensive.
You can write your own modules in native code to extend Titanium's capabilities.
It's open source.
They recently changed their support offering removing the 5 app limit, much more affordable.
You can change a view js code while running the app in the simulator, you will see the results when you reload the view you're editing. That's a boon :) (exception: there's no way I know of to reload the code in app.js)
CONS
Debugging is a pain. Haven't tried out Titanium Studio yet, it might be a big improvement.
Adding too many views tends to degrade performance faster than using native code.
The Titanium Developer app on Mac has plenty of interface glitches and you might find yourself restarting it pretty often.
In some versions the print to console debug statements are broken.
You will often stumble into cross-platform abstraction leakage.
Support on the forums is a bit light, many issues you will encounter are not big but still annoying.
Need to pay attention to JSON correctness, the included parser tends to be picky. Using eval is always an option.
Compile times and loading in the simulator are not that fast, titanium objc is pretty big.
Compared to Xcode, Visual Studio & even MonoDevelop, Titanium Studio feels slow (real slow), buggy (restarting several times each day, even reinstalling a few times) and of course you've got to deal with JavaScript... We found that the pain of developing in Titanium was too great, especially when you have competent iPhone & Android devs around so -
We looked long & hard into the best option for cross-platform dev & ended up using Mono - Touch & Droid. It's been great, we do actually share 80% of the code between iPhone & Android, & we're just beginning a port to WP, which is going well (again sharing 80% of the code). Of course it's not a miracle fix - you still need to know how to develop for each platform. I've even grown to like C# almost as much as Obj-C now :-)
Obviously, some will disagree.