Related
I'm interested, what are the tools for good practice iPhone software development (and other apple devices), except XCode & Interface Builder.
I'm talking about tools for making application prototypes, icons, classes diagrams, images, etc.
This question came up after a time of strugling with Gimp for image edition, and Axure for prototype making. I'm sure, these are not the best tools for my aims. I'm thinking of bying photoshop, or may be it's better to use some cheaper and usefull application for icons and prototypes specially.
Although, it would be good to know, if there are some convenient tools for some other purposes that i didn't mention above.
i'm using Acorn for image editing
OmniGraffle is great for rapid prototyping.
I have also used Bluprint for iPad and it is also quite nice
As Apple has removed the restriction for java and flash should I go for these tools or just continue developing iPhone/iPad apps using Apple tools(Xcode, objective C .. etc).
I want to know the benefits of using apple tool instead of java or flash.
Thanks
Java is not an option anyway. There is no Java runtime for the iPhone that you can use to produce apps.
This is a no brainer. For iPhone, use Apple's SDK. You'll get latest APIs first than in any other platform, better performance, and, what's even more important, you are sure that Apple will keep pushing its API. With other products (like Java, Flash or Mono) you will always fear they changing their policies when they want. No guarantees.
It really depends on what kinds of apps you are making.
If you are just making a basic app, that you want to look like the standard Apple apps, you shouldn't switch.
If you really rely on Flash as a base, you should use that.
If you have little experience with Objective-C and prefer to code in C#/.NET, you may go for MonoTouch.
It really depends on your preferations, but if you want the most stable, reliable, and supported platform, you should go with Objective-C.
In my eyes, you should really only be using anything other than the standard Objective-C if it is utterly necessary, as others have pointed out; with Apple, you get the latest API's first, better performance, etc.
For new development I would jump in and use Apple's frameworks with Objective-C. If you're entering a new country you should speak their language. However, which development framework you choose will be largely dependent on whether or not you have an existing product. If you're just trying to target a new platform with an existing code-base it may be in your best interest to use an intermediary framework like MonoTouch or Adobe's Packager for iPhone.
If your codebase is Java, you'll be starting from scratch in Objective-C. Java is not currently available in any form on iOS.
If your codebase is in ActionScript 3, you may want to explore Adobe's Packager for iPhone. It will likely have a shorter path to market if your are porting an app already developed on ActionScript 3, but you will always be at the mercy of Adobe's intermediate layers. I know less about the Adobe bindings and how your application actually compiles, so I can't speak to any additional technical-risks there.
If your codebase is in C#, you may want to look at Novell's MonoTouch. Again, this may result in a shorter time to market. You still need to develop on a Mac (MonoDevelop only works on a Mac), and some .NET APIs are not available on Mono.
In any other circumstance I'd pick up Objective-C and use Apple's SDK directly. It's always tough to learn a new language (especially one as different as Objective-C), but it's worth it in the end.
Use the tool that will make the most sense for your goals and the experience you want to provide your users. Apple's lifting of restrictions only removes one risk: that using a framework not endorsed by Apple will be the sole reason for App Store rejection. The lifting of restrictions will not remove other risks that may exist like:
Continued support by third-party vendors (Novell, Adobe) of their frameworks.
Inability to target/test against the newest version of iOS until third-party frameworks add official support.
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.
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.
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 ^^