I'd like to start developing applications for iPhone, but I'd really like to use OCaml rather than Objective-C. After some googling, it seems like this is definitely possible, but I haven't found any code snippets which actually compile.
Is it possible to write iPhone apps using OCaml? If so, could you provide a snippet demonstrating how to make calls into the Cocoa API from OCaml?
We have instructions for building an OCaml-to-iOS cross compiler on our site. We started with the patches mentioned above, but we found they needed to be modified in several ways to run on a stock iPhone/iPad. We are selling an iPhone app named Cassino that is entirely written in OCaml (except for thin wrappers to Cocoa Touch). Wrappers for all of Cocoa Touch would be a big job, but wrappers for a single application aren't so bad. And coding in OCaml is very pleasant compared to ObjC.
We also just published full sources for a small OCaml iPhone app named Portland at our site. Read more at psellos.com.
Out of the box, OCaml cannot be used to build IPhone apps. You would have to have OCaml output ARM code rather than x86 code. You would also have to build wrappers for all the IPhone API calls.
Still, these guys are going through the pain to try this.
http://web.yl.is.s.u-tokyo.ac.jp/~tosh/ocaml-on-iphone/
My humble recomendation is that you focus on using Obj-C for everything. If
you really want an ML, use it only for the kernel or the interesting portion.
I would find an *ML that code gens to something like C, and then use that result
as a library to the app.
Good luck.
Related
We're about to build an app for both iPhone and Android, and it would (of course) be glorious to only build one application that could work on both platforms. My question is, how easy is it to drop out of these cross-platforms into native code for certain views/activities?
In other words, if I find that Titanium is terrible for a particular task, can I just write that in Objective-C for iPhone and Java for Android or does that involve a bunch of hacks? I'm hoping we'll be able to build the basic stuff cross-platform, but I'd still like to be able to drop to native code if I start hitting snags or some hardware feature is poorly supported. We're leaning towards Titanium since we (as a shop) are unfamiliar with Ruby, but Rhodes is something we're definitely looking into as well.
From what I've read, the jury is out on these frameworks, so I'd like to have fallback options in case the app becomes buggy/unwieldy halfway through. I realize that a lot of this depends on exactly what you want to do with the app, but we're still trying to figure out what we CAN do cross-platform first...
you can write modules for each of the platforms, how easy it is to drop out and integrate them into you application would depend upon what you are trying to accomplish.
http://developer.appcelerator.com/doc/mobile/iphone/module_sdk
http://developer.appcelerator.com/doc/mobile/android/module_sdk
if mono touch is available than why we should use mac environment(sdk,xcode+Interface Builder)?
what are the disadvantage of monotouch compare to xcode?
I always prefer working in the language that is most philosophically aligned with the platform I am developing for.
That is to say, the frameworks the whole platform is built around were written for and in Objective-C. As such, if you are working in Objective-C yourself for a while you understand why things are built the way they are, and can also anticipate calls that might exist or behaviors.
Just as I would not develop for Windows Phone 7 in anything but Silverlight, I would not program the iPhone in anything but Objective-C in order to get the most out of the platform. New language? That's a benefit as people should learn new languages now and then anyway. And it's not like it saves you that much time to use a language you already know since a large majority of your time will be spent learning the frameworks (which MonoTouch lets you call into).
I feel like this needs an answer from the MT camp, too.
Why eat fish, if you can have meat? Why speak German, if English is understood? Why watch CNN if there is FOX? Why vote vote for the Republicans if there are the Democrats? Why...? And so on.
It is your choice! If you have worked with C# for a long time and want to have quick results on iOS, go MonoTouch. Especially if you have a collection of APIs or methods you can reuse, MT is the way to go. If you want to learn a new language (ObjC), go for it. Even if you use MT in the end, knowing ObjC is somehow crucial because it helps you understand why things work as they do.
Hello here is my personal opinion,
I've also been on .Net world for a while, when iPhone launched the ability to create native apps, it called my whole attention and i really tried to learn objc, i took 2 books and started trying and trying and trying like for a month and then I left iPHone programming due to you had to make tons of things than on .NET was a line away for example the GC.
When Miguel de Icaza launched MonoTouch i gave it a try and i realized that most of my previously done code was fully funcional (i've always tried to separate ui code from business code) and this is really the point of .NET on the iPhone, to bring most of your already done business logic to the device.
Also on objc you wont find anything like LINQ or var keyword, consuming web services on MonoTouch its just a few clicks away etc.
If you want to target the Android platform there is also MonoDroid (monodroid.net) wich its coming out later this year the stable release, you can give it a try right now on the beta state. Also if you want to target Mac OSX there is MonoMac. So you can share class libs between all this 3 platforms (also al mono/.net supported ones) without hassle not to mention it will work on windows too and viceversa (when possible) (Also dont forget about WP7).
The only thing you will need to worry about its the UI but most of your business logic should work. here is a complete list of .NET Assemblies supported in MonoTouch http://monotouch.net/Documentation/Assemblies and also MonoTouch exposes a C#/CIL binding to all the CocoaTouch APIs.
Also the support of the MonoTouch team is awesome you can just get on IRC ans ask a question and it will be answered right away, mailing list too :)
I really enjoy MonoTouch, i know that no language is perfect for all tasks, and Objective-C is no exception.
Every example, tutorial, and piece of documentation will be written in Objective-C, and mono will just be calling into Objective-C code under the hood. If you really feel like C# is worth mentally translating everything, and adding an extra layer in your code, go for it I guess.
As a C# developer, I've found Objective-C to be horribly painful to become confident with. It's taken about two months, and two excellent resources to get to this stage.
Get your Visa card out, you'll need to spend a total of $54.
1. The free Stanford "Developing apps for iOS" lectures.
Pure brilliance, and it makes learning Objective-C very clear.
http://itunes.apple.com/us/itunes-u/developing-apps-for-ios-sd/id395631522
2. The iOS Apprentice series.
This is where you'll need to cough up the $54. It teaches you, step by step, how to program in Objective-C, and the apps you build are actually pretty impressive. Part 1 (of the 4 parts) is completely free, so you can give it a go before parting with any cash.
http://www.raywenderlich.com/store/ios-apprentice
I've yet to find any iOS books which match the clarity and friendliness of these two resources.
Finally, don't buy any books unless they specifically say that they're for iOS5 and XCode 4. This latest version of XCode is simply too different to make them useful.
Disclaimer: I don't work for any of the resources mentioned in this thread !
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.
I have made apps for iPhone, but want to also code for the Android but want to know if it is first worth my time, second worth my having to learn another language, and third worth the effort in the sense that am I going to make a profit from this. Also if in any way Android code is similar, then will it be hard to bring the iOS (Xcode) files, or copy and paste my iOS code into the Android code.
It's a most definite no. As iPhone Guy pointed out, there's a major difference in the languages both platforms require. iPhone uses Objective-C whereas the Android is based on Java (don't know if it's Mobile Edition or "regular" though). In addition, it's a completely different set of APIs. iPhone uses a modified form of Cocoa called Cocoa Touch whereas the Android makes uses of Google's SDK for it. In answer to your question, you won't be able to copy/paste your code between the languages. Your Objective-C code won't compile to Java and vice versa.
Yes -- programming on the iPhone uses Objective-C while programming for Android is in Java. Although they use similar concepts, the two languages are different.
I was a Java programmer before switching to Objective C. Personally I like Objective C better than Java, but that's just a personal opinion ;)
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 ^^