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.
What programming languages can one use to develop iPhone, iPod Touch and iPad (iOS) applications?
Also are there plans in the future to expand the amount of programming languages that iOS will support?
Apple lifted the restrictions on non-Objective C/C/C++ apps -- you just can't load code that isn't in the app bundle.
MonoTouch lets you use .NET languages -- C# is directly supported, but if you have Windows, you can make assemblies in any .NET language and use it.
There are rumors that Apple is going to support other languages directly -- I keep hearing ruby, but they are just rumors.
I think Lua is being used for game logic on a lot of apps.
EDIT (in 2018): Generally you can use any language that you can get to compile for iOS or even install language interpreters. The main thing you cannot do is load code from the Internet that wasn't in the app bundle.
People do this all of the time anyway (see React Native apps loading JavaScript from servers), but, technically, it's not allowed. The main thing that will get you attention from Apple if you make some kind of App Store that loads whole App-like things.
EDIT (in 2020): from #Pylot in comments: I know this is a long time ago, but now at least technically you can load code that isn’t embedded in the app, as you can write with JavaScript using the webview. Not staying your answer is wrong or anything, I definitely agree with you. but I was looking for something and found this post on the way. Figured if anyone sees this it might help them out.
The SDK agreement and App store guidelines have been changed (circa Sept 2010).
You can now probably use any compiled language that will compile to the same static ARM object file format as Xcode produces and that will link to (only) the public API's within Apple's frameworks and libraries. However, you can not use a JIT compiled language unless you pre-compile all object code before submission to Apple for review.
You can use any interpreted language, as long as you embed the interpreter, and do not allow the interpreter or the app to download and run any interpretable code other than code built into the app bundle before submission to Apple for review, or source code typed-in by the user.
Objective C and C will likely still be the most optimal programming language for anything requiring high performance and the latest API support (* see update below), as those are the languages for which Apple targets its iOS frameworks and tunes its ARM processor chipsets. Apple also supports the use of Javascript/HTML5 inside a UIWebView. Those are the only languages for which Apple has announced support. Anything else you will have to find support elsewhere.
But, if you really want, there are at least a half dozen BASIC interpreters now available in the iOS App store, so even "Stone Age" programming methodology is now allowed.
Added: (*) As of late 2014, one can also develop apps using Apple's new Swift programming language. As of early 2015, submitted binaries must include 64-bit (arm64) support.
With plans to slowly retire the long-used Objective-C, Apple has introduced a new programming language, called Swift, for designing apps and applications to run on Apple iOS devices and Apple Macintosh computers.
Apple says:
"Swift is a new programming language for iOS and OS X apps that builds on the best of C and Objective-C, without the constraints of C compatibility. Swift adopts safe programming patterns and adds modern features to make programming easier, more flexible, and more fun. Swift’s clean slate, backed by the mature and much-loved Cocoa and Cocoa Touch frameworks, is an opportunity to reimagine how software development works."
Introducing swift
What programming languages can one use to develop iPhone, iPod Touch and iPad (iOs) applications?
Ruby, Python, Lua, Scheme, Lisp, Smalltalk, C#, Haskell, ActionScript, JavaScript, Objective-C, C++, C. That's just the ones that pop into my head right now. I'm sure there's hundreds if not thousands of others. (E.g. there's no reason why you couldn't use any .NET language with MonoTouch, i.e. VB.NET, F#, Nemerle, Boo, Cobra, ...)
Also are there plans in the future to expand the amount of programming languages that iOs will support?
Sure. Pretty much every programming language community on this planet is currently working on getting their language to run on iOS.
Also, a lot of people are working on programming languages specifically designed for touch devices such as iPod touch, iPhone and iPad, e.g. Phil Mercurio's Thyrd language.
The programming language of iOS(and Mac OS) is Objective-C and C. You have to use Xcode platform to develop iOS apps, on the next version that is now available on beta release, Xcode 4 supports also C++.
It is also now possible to use OCaml for developing iOS applications. It is not part of the standard distribution and requires modifications provided by the Psellos company. See here for more information: http://psellos.com/ocaml/.
This might be an old thread, but I'd like to mention Appcelerator Titanium, which allows anyone versed in HTML5/JavaScript/CSS to develop iOS applications.
Only Objective-C is allowed by now... but since a few months ago you are allowed to write scripts that will be interpreted in your application.
So you may be able to write a LUA interpreter or a Python interpreter, then write some part of your application in this scripting language. If you want your application accepted on the App Store, these scripts have to be bundled with the application (your application cannot download it from the Internet for example)
see new app store rules
objective-c is the primary language used.
i believe there is a mono touch framework that can be used with c#
Adobe also is working in some tools, one is this iPhone Packager which can utilize actionscript code
You can use "smart BASIC" programming language. It is a genuine but very advanced BASIC language with all its power and simplicity. Using its free SDK, BASIC code can be easily published as a standalone App Store application. There are many apps in App Store, written in "smart BASIC" programming language.
Apple doesn't want anyone to create iPhone apps outside of the Xcode/Objective-C environment. How can they actually enforce this?
If the non Xcode IDE, for example Unity, compiles to an iPhone executable, how will Apple know which dev environment you used to create the app? Can they have Xcode compile some sort of signature into the executable that no one knows about?
For tools such as unity, corona, flash, and other platforms used to 'generate' iphone apps, Apple may be able to 'decompile' and examine your app (look at patterns of generated functions, etc). From this, they might be able to guess that your app was generated with such a tool.
In the limit, this is impossible. Consider the following: I write some script code to generate a bunch of objective-c code. Then I manually import the objective-c files into xcode and build the app. How would apple be able to distinguish the script-generated code from human-written code? Maybe I just tend to write code that happens to look machine-generated. There's no way for apple to determine whether the code was "originally written in objective-c, c, c++ or javascript" or not, yet this would still, technically, violate the agreement. That's why the 3.3.1 part of the agreement is nonsense.
Most automated systems do things a particular way, which isn't hard to detect. If you've ever looked at the PHP or JavaScript code Adobe Dreamweaver generates, for example, you know how easy it is to find stuff like this.
Apple is doing this to prevent people from using Adobe's Flash development framework. It should also be noted that Apple's decision to limit Application Frameworks like this is causing the DOJ/FTC or some government agency to start an informal inquiry into monopolistic practices.
From this article:
"According to the Post's Hollywood source, Apple's ban of Adobe's Flash technology on the iPhone and iPad is what prompted the government to poke around. "
They really don't have an issue up until now with other frameworks because Adobe didn't have one based with the Flash environment. Now that there is one, Apple is going to restrict anything that talks/looks/smells/acts like an Adobe Flash app on the iPhone. In my opinion, they won't do anything to other frameworks, but they'll enforce the rule just for Adobe. Which brings up the whole monopolistic practices thing.
I believe that many of these translator tools have some kind of common runtime function library which take care of the portions that could not be translated 1:1. Those function could then be pretty constant regardless of your application. That way there would be no real need to decompile the app. but instead just look for usage of those function signatures.
FWIW I find the whole idea of limiting user's choice of tools is a bad move.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
A recent post by John Gruber notes that the following legalese:
3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.
Has been revised as follows:
3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).
And makes the following observation:
My reading of this new language is that cross-compilers, such as the Flash-to-iPhone compiler in Adobe’s upcoming Flash Professional CS5 release, are prohibited. This also bans apps compiled using MonoTouch — a tool that compiles C# and .NET apps to the iPhone.
Does this in fact ban the use of Monotouch for the IPhone?
Update -
This changed recently. MonoTouch should no longer conflict with
the agreement. Any statements below are purely historical!
Yes, it seems pretty clear from their license agreement now that if the original application is written in C# then it would be violating the license:
...Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine...
They even hammer it in a little further:
Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited
Kind of a bummer, MonoTouch and the Flash CS5 -> iPhone converter are very cool.
Update:
Apple has dropped (almost) all technical requirements for languages and libraries for iOS, so MonoTouch is without a doubt a viable solution. See Apple's announcement.
Most people here simply want to take Apple's document by the word and say "yes, its banned". Well, here's my point of view: at this point, nobody really has any idea if MonoTouch is going to be banned or not, and I'll explain why:
The Apple agreement version 3 (not the latest, the one before) clearly states that its illegal to use any other frameworks to develop applications other than the ones provided by Apple:
3.3.2 An Application may not itself install or launch other executable code by any means, including
without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise.
No interpreted code may be downloaded or used in an Application except for code that is interpreted and run
by Apple's Documented APIs and built-in interpreter(s). http://adcdownload.apple.com/iphone/iphone_sdk_3.2__final/iphone_sdk_agreement.pdf
Even though that's the case (and was actually the case since 2.x, apple doesn't have any problem accepting applications that do exactly that. For example, ALL EA games use Lua scripts, and lots and lots of people use external libraries that are not native to the iPhone. Even when the iPhone has those native APIs, Apple never had a problem accepting applications with different versions of it, like SQLite.
My point is that saying "YES, they'll be banned" right now is simply WAAY too early. The only clear thing at this point is that Apple could in fact use that to ban apps. Just like they accept Apps today that are against some of their rules, they'll probably continuing doing so.
There's also the fact that are hundreds (or probably a few thousands?) of apps in the store currently running Mono, and Apple will need to accept updates for those apps. Major apps with millions of sales were created using Mono (and Lua), and I doubt they would refund every single user.
Lastly, Enterprise applications are deployed to iPhones without Apple's approval, and that's a big market that MonoTouch is on (I myself develop enterprise apps). There's no way at this point that Apple could ban MonoTouch for those applications, and that will probably be enough to keep MonoTouch alive for a long time.
Update:
New changes to sections 3.3.1, 3.3.2 and 3.3.9 have made MonoTouch (and all other cross compilers/languages/etc) perfectly acceptable on the iPhone. See Apple's announcement
Miguel doesn't seem to think so. See the tweet and Miguel's response. Lets not overreact here and say that Monotouch is dead, or stop developing with Monotouch until some clarifications have been made by all parties involved.
That said I would definitely start putting the heat on Apple for such draconian development policies. Things like this, and the nebulous process that is the approval policy of iphone/ipad/touch apps should strike fear into the hearts of developers. What's next, their license stating that the only Ad platform you are allowed to use is iAd? Not allowing the distribution of free apps without iAd? Slowly raising Apple's share of the revenue of app sales? As developers in a locked down eco-system, we are kind of frogs in a pot of hot water, and Apple is slowly turning up the heat. Now is the time to explore other mobile platforms, because as they get better, the main thing holding people to the Apple platform is lack of applications on other platforms.
I spent months of evenings working on ideas for a killer iPhone app in Objective C. My day job is C#. I downloaded MonoTouch C# when it became a viable alternative and have just spent 3 months converting my code to iPhone specific MonoTouch C#. Which stopped me going mad through switching from C#/Objective C.
What do I do now throw it all away and start again or give up!?!
I feel really sorry for the Mono guys. This is plain wrong. It is one thing to stop Adobe who haven't launched their product and have no customers and to stop MonoTouch who do and also have approved product in the AppStore.
Why would anyone want to build a business and invest in Apple when they will take it all away at a moments notice without being answerable or questionable?
Clearly developers and customers of Apple caring for them and their products is a one way street.
I hope Apple gets trounced for this ridiculous policy. Arrogance is not attractive and generally bad for business. This is one of the reasons I haven't started iPhone development.
Most hardware and OS providers are happy to have additional tools and audience to write to their platform. Apple is taking the stance that its (braindead) tools are the only game in town.
The "Big Brother" ad from 1984 is more and more relevant...
EDIT
The way it is written also seems to imply that if I wrote a .net to objective C/apple translator that the code isn't acceptable because the original code was not objective c. That is ludicrous (and unenforceable.)
Unity is also based on Mono and with that being a sizable commercial product I imagine that this is an issue which we've not heard the end of yet.
Banning all apps that are not written in Obj-C/C++ would, in theory ban all Unity games also, of which there are a large number already in the app store.
This question has also been asked over on the Unity Answers site, and their official answer is:
"We just heard about the iPhone OS4.0
and the new Terms-Of-Service. While we
believe we are fully compliant with
these we are right now doing all we
can to get this verified by Apple. As
soon as we know precisely, we will of
course share that info with everybody.
Please hang tight while we get this
sussed out."
Be interesting to see what they get told by Apple.
The thing is, surely saying that an app has to be written in a certain language is a bit of a misnomer, as once the app is compiled down, it's always a native binary regardless how it's been built. My guess is that all they can look for is some kind of signature in the binary to detect what tool it was built with. A flawed approach.
EDIT: There is an interesting overview of the situation on this blog: monotouch now dead in the water what does apples new iphone developer agreement mean
The new license agreement is explicitly clear about that. So YES, it will be banned.
Advice, if you want to really develop for iPhone, try XCode. If you are already familiar with Java or C# or yet better C++, then learning Objective-C wont be that hard.
iPhone/iPad is Apples new successful business, and they will do anything to keep this business growing, maybe they will not ban Monotouch apps now, but who knows there next move? So if you are really really interested in iPhone dev, instead of having nightmares that your work might be just rejected. Just switch to XCode, at least that will lower your app reject percentage. Hence, my advice.
I think something to strongly consider is Apple's motivation.
I agree with other sentiments posted online that Apple is trying to prevent commoditization of applications - that is to say, having more and more applications written using frameworks that generate applications that can run across multiple devices.
But that's not what Monotouch is. Monotouch is all about using the Apple frameworks to write applications - but through Mono, not Objective-C. So from that standpoint what Monotouch is doing is not something that should really bother Apple.
I still hold that developers are better off writing in the native language of the platform they are using, as things are just generally smoother when you don't introduce system that can have abstraction impedance mismatch - the Cocoa frameworks were all built to be used from Objective-C, and they make the most sense when you are used to the philosophy of Objective-C. But I do hope that Apple comes down on the side of allowing MonoTouch to be used.
All Apple is saying is that you must all now use 1980's languages to develop your competition beating state of the art Mobile Applications....
Makes perfect sense. Sounds like a winning strategy to me.
It also stops you from using any 3rd party libraries that you can't guarantee that have been developed in straight C, C++ or Objective C.
So basically it means that you can't buy in Games API's such as Unity.
Just adding my 2 cents. It seems that after reading this part: (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited) there is nothing to discuss. They have expressed them unambiguously. Not only they are banning MonoTouch and Unity3d, it seems they are also banning Titanium Framework. However, after reading this article, i found myself really confused.
I am not familiar with US laws, but is it legal? I mean, aren't they breaking some anti-monopoly laws?
Besides all of this, i can't understand their motivation. Not only will they partly lose a developers interest, they will also lose a developers respect, i think.
As of today, Section 3.3.1 of the Apple iOS Developer Program License has now been reverted to the old text:
3.3.1 Applications may only use Documented APIs in the manner
prescribed by Apple and must not use
or call any private APIs.
Apple has released an official statement on the license changes.
This would indicate that it is now permissible to use MonoTouch.
One goal of the Mono team is porting Silverlight to the iPhone by mean of MonoTouch/Moonlight for cross platform development. That's a bit like porting Flash to the iPhone. There is also Monodroid on the way to help us porting applications and, you know, Apple runs amonk every time someone says "Android" :-) IMHO, if Apple is targeting Adobe with the new agreement, they are targeting Novel too. We are probably speculating and there's a NDA but many of us invested a lot of time on this platform so we need to make the situation clear. We cannot wait next summer to discuss this matter. For example, I've been asked by a friend to help his company to prototype a MonoTouch application for a customer. Does the new agreement only affect the App Store distribution? What about in-house distribution?
This google docs spreadsheet has a long list of apps that will be affected by the new agreement. Some noteable ones that have been #1 in the appstore for their category:
Monopoly
Lemonade Tycoon
Skee ball
The settlers
Zombieville
One of the funny inclusions is Toy Story.
oMany apps have been accepted within the last few days written with the help of monotouch and unity, whereas I also am using it as well as obj-c, since the announcement and change in the agreement, so GO FIGURE,...the good ol'WTF comes to mind. It is a bipolar piggybank it seems.
ALSO, the last Unity Game GiantMOTO, which is under HOT NEW GAMES - YESTERDAY, has on its splash screen onLoad in big letters, POWERED BY UNITY. So, all the conjecture, assumptions, etc. is really out the door. It might say all that in the new version, it is certainly NOT enforced. And montouch is the only development platf that FULLY exposes iPhone API and builds COMPLETELY into obj-c using XCode.
From what the license agreement says MonoTouch apps will clearly not be allowed in the AppStore.
The more interesting question is though, against which framework / apps will they enforce it? They will also have to write automated tests to check if the apps were written natively or not, because the people who approve the apps won't have the time / skills to do it for every single app. These apps won't put a sticker there 'Using MonoTouch / Flash'.
Short answer to all that blob in the agreement is YES.
Apple is basically shooting itself in the foot by limiting programs to a few languages:
C - which is not really suited for application development these days, due to it's low-level nature. It's mostly a systems programming language today.
C++ - which makes it harder to shoot your phone, but when it happens, it's with a bazooka. Apart from Qt, there aren't any complete application frameworks to use in C++ (and Qt doesn't support iPhone - yet).
Objective-C - which was invented by Apple and of course will be supported.
JavaScript running in WebKit - basically a web application.
They are deliberately limiting what tools you can use to develop for iPhone, which will almost certainly get them in serious trouble. I'm sure a good sized chunk of the community will just quit iPhone development and migrate to a different platform like Windows Mobile, Symbian, Android or Maemo, which are totally open - you are free to write your application in LOLCODE.
Apart from possibly making iPhone junk for developers, it also gives Adobe a nice kiss:
Apple deliberately blocks Flash from iPad, and now they are also blocking it from iPhone. The nummer is Adobe Flash's CS5 biggest feature is deploying Flash applications to iPhone.
tl;dr: Apple is basically shooting itself in the foot with this move.
It's now months after the flash debacle and it's pretty obvious Monotouch and Unity are doing just fine.
As per "Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited"
Monotouch compiles code down to a native binary, there is no "layer". They're referring to somethign like a .NET runtime, Java JVM or Flash runtime.
Mono applications would normally compile to bytecode which is and would require JIT (just in time) compilation to run them thus a .Net framework or Mono framework is required. However, in the case of iOS and Android, Mono application compile to native code. Therefore, in the eyes of Apple, there is no third layer, Apple will never ban Mono. So you can feel free to develop with MonoTouch and distribute your apps. To ensure you further, there are various of Mono applications (including games and applications) on the AppStore that have been around for a long time.
Hi I'm looking into iPhone development, and Objective-C is not be my preferred language. As far as I can see at this moment Ruby cannot be used to talk to Cocoa Touch at the moment on the iPhone.
So my question is, am I wrong? Can I use Ruby on the iPhone to develop Cocoa Touch applications. And what is the future looking like for Ruby on the iPhone?
Now you can with RubyMotion
In the iPhone OS, mprotect() will fail if you try to use it to mark writable sections of memory as executable. This breaks bridges like RubyCocoa (and probably MacRuby) that use libffi to create Objective-C method handlers at runtime. I believe that this is by design because it was not always the case.
Ultimately, this is more a matter of platform politics than technology, but a technical workaround for this exists. Instead of generating custom method handlers at runtime, precompile a pool of reconfigurable ones that are assigned as needed, essentially making the bridging process entirely data-driven. As far as I know, this is not yet being done in RubyCocoa or MacRuby.
Another significant thing to consider is that the compiled Ruby and RubyCocoa runtimes can be significantly larger than compiled Objective-C apps. If these libraries were available on the iPhone, this wouldn't be an issue, but for now, even if you had RubyCocoa working, you might not want to use it for apps that you distribute.
No, you are correct. Currently, and most likely for the foreseeable future, Ruby will not be an option, at least for AppStore applications. There's no reason you couldn't do this on a Jailbroken phone, but Apple is pretty wed to Objective C for official development.
You are better off as a programmer knowing a number of different languages - think of Objective-C as a good learning opportunity.
I've found that things you learn in other languages often make you a better programmer overall, and give you new insights into other languages you already know.
rhomobile is an option to run ruby code on the iPhone, but it's essentially web app development. A web server runs locally on the iPhone and your ruby code renders to standard client side web technologies (html/css/javascript).
http://rhomobile.com/
Actually, the ruby cocoa bridge isn't awkward at all; things work remarkably smoothly, right down to connecting outlets in IB etc. The resulting code is down right beautiful.
As for iPhone development, if you want an official AppStore application, you're out of luck unfortunately. Apple dictated that iPhone is Obj-C/Cocoa Touch, and there's a clause in the SDK license saying that one of the things they will reject an app for is having a language interpreter/JIT compiler, so you couldn't add a ruby interpreter in your app yourself.
Off topic, but hilariously, this is why Flash for the iPhone is Adobe blowing smoke. They couldn't get a swf player onto the AppStore even if they wanted to, per Apple's license.
Uh, Rhodes (Rhomobile) does allow you to do native apps on the iPhone and all other smartphones. Yes, we do leverage doing rendering via the WebUIView control. But we allow all device capabilities and synchronized local data.
You might want to take a look at shinycocos. It is a child project of cocos2d-iphone, an Objective-C game programming framework for iPhone.
I haven't yet played with it, but from the git README I infer that it bundles Ruby 1.9.1 into your app.
I installed the ruby package from Cydia on my iPod Touch 1G jailbroken on 3.1.3:
Seems to work.
Now as for cocoa-touch that is a whole different story I would assume.
Take a look at http://www.appcelerator.com/products/titanium-mobile/
"Native iPhone and Android apps built with Web technologies."
Sounds good isn't it ? ;-)
No you can not create iOS native app in Ruby.
There is only two options for native apps for mac and iOS:-
Objective C and Swift Programming Language
Tutorials:-
Apple's official tutorial on Objective C
Apple's official tutorial on Swift Programing Language
If you are familiar with Ruby and only want to create iOS apps by Ruby. Ruby Motion, can be a cross-platform option for you, but it is not free.
Cross-Platforms
RubyMotion
Xamarin required .net skills
appcelerator HTML,XML,CSS,JS skills required
phonegap HTML,XML,CSS,JS skills required
I imagine it won't work right now, but I'd imagine that you'll eventually be able to use MacRuby to build iphone apps. Apple are putting a lot of work into it
Here's a link to an ADC article describing how to build normal cocoa apps
You don't have to use Objective-C to write iPhone apps. If you use QuickConnectiPhone, http://sourceforge.net/projects/quickconnect/, you can write it completely in JavaScript, CSS, and HTML and still have an installable application not a web app.
If you know ruby you are probably working with JavaScript already.
To see how to install it, run it, and other ideas go to tetontech.wordpress.com
There's an open-source Ruby-Cocoa bridge you might try to get working. But I gather that there's a bit of an impedance mismatch between Ruby and ObjC that makes it a bit awkward to use.
The Ruby Cocoa bridge probably will not work. Most of the bridges for dynamic languages need to generate executable thunks (either manually or with libffi). More limited bridges (for more static languages) may not have such issues.
In either event, bringing up a bridge is probably going to require becoming more familiar with the Objective C runtime than one would just learning how to write Cocoa Touch apps, which probably defeats the point of doing it in the first place.
Currently isnt true, Apple change their policies, take a look at ShinyCocos, is a ruby bindings for the Cocos2D-iphone game framework.
https://github.com/funkaster/shinycocos
One possible solution would be to create an application wrapping for example the rice library (google it) which includes a ruby-vm. I reckon you would be able to create c++ wrappers that you could expose to ruby, thus making an environment for iphone development with ruby. This probably requires a lot of work though ^^