Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have found the "Getting Started" documents for developing apps on iPhone.
I wanted the community's opinion on what I should know/learn (in terms of languages or concepts)?
How long would it take for a moderate programmer to learn and build an app that manages a list, connects to certain websites, etc?
How to get an app I made onto the iPhone? Just ZIP then install with .ipa file?
I wanted the community's opinion on what I should know/learn (in terms of
languages or concepts)?
You will be using Objective-C and Cocoa. These are fairly strange concepts to crasp if you have not done MAC programming before, but after a short while you will probably fall in love with them. The most important concept to remember with iPhone development is memory management as the device has no concept of garbage collection.
How long would it take for a moderate programmer to learn and build
an app that manages a list, connects
to certain websites, etc?
Not too long. There are a multitude of example applications on the internet, and many helpful folk on stackoverflow.com
How to get an app I made onto the iPhone? Just ZIP then install with
.ipa file?
You will need to download the SDK, create an app using xcode on the mac (or similar environment for windows if there is one) - you can test with simulator without giving apple anything, but in order to legitimately test on device you need to become an apple developer.
However If you jailbreak your device, you will be able to follow one of several methods to get your application on the iphone bypassing apples restrictions.
The whole iPhone UI development (UITableView etc) is based around the MVC (Model-View-Controller) pattern, so a good understanding of that is vital.
Memory management is also vital and can be a little cumbersome to start off with. I have not long started so can not give you a good description here without making a fool of myself :). Apple Memory Management
Finally the development environment can be a little wierd to start off with. Especially hooking up the view controller and interface elements. So check that out.
Then its basically looking through the tutorials on the iPhone developer website and the internet to learn the intracacies of the different UI elements and controllers (tables, textboxes etc).
You will need to pay for the iPhone Developer program to legally use your iPhone to debug your applications (although the Xcode dev environment comes with a simulator). Submitting the application to the app store allows access by everyone. Full details for doing this are available after paying your money. There are other ways you can get apps on the iPhone but I will not provide details for doing that - search the internet.
I would say that looking through the documentation and following tutorials will get you far enough to start building applications. This should not take to long. A good book may also help you out here, try the iPhone Developers Cookbook, which gives good well discussed and broken down examples about specific issues and broader coverage of things like tables etc.
Objective-C. Pay close attention to memory management, i.e., retain, release and autorelease.
Took me about a month (part time) to get something that pretty much worked. And then another month to refactor after learning what I'd done wrong the first time. This was while the NDA was in place so it would probably be easier now.
You need to join the iPhone Developer Program. Installing a development app is just a matter of running from XCode once you have you certificates sorted. (Check the iTunes Connect documentations. It's pretty good.)
Installing on someone elses iPhone is a matter of figuring out ad-hoc deployment (hard) or uploading to iTunes (easy).
First of all: buy a mac if you don't have one already, the windows tooling pipeline is basically non-existant. And trying to run OSX on non-apple harware is illegal in most situations.
Download the iPhone SDK. http://developer.apple.com/iphone/ should have everything you need.
Objective-C is a little bit on the strange side but a moderate programmer should be able to pick it up quite quickly.
Installation: i have no idea sorry...use the app store ;)
Learn objective C and work with Cocoa. There are far more examples of that floating around than iPhone code. Depending on what environment you are used too, Xcode and the experience of developing for the iPHone can be quite a change so get ready to buy some books and spend lots of time scratching your head!
Learn how to navigate Apple's docs.
For example UIView Class Reference.
Took me a little while to get savvy. XCode also has an excellent documentation browser integrated into the IDE. Once you can translate what the docs are telling you into code, the whole API opens up.
Use the Research Assistant in XCode. (Under Help Menu) That thing rocks my world. Highlight a class like ABRecordRef and it will give you a quick synopsis of what it is and how to use it, with links to the reference docs.
The one bad thing about Apple's docs is that they don't have clear examples of how to call a method in the discussion of the method. This is a glaring oversight, IMO. So many time I just wish there was a simple example for how to use something and I wind up going to Google for it.
The above information is quite good, but I'd add that getting familiar with the documentation within XCode is very valuable. This means you need to go to the DOC SETS part of the Developer Documentation window and make sure you have the documentation for the iPhone OS you're coding for. I spent a bunch of time writing code that depended on methods in NSObject that are available in Cocoa but not on the iPhone OS.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I want to build a mobile/tablet application whose core feature will be taking pictures with the camera , viewing pictures and receiving notifications. Also I want to target iphone, ipad and android platforms.
Titanium appcelerator piqued my interest because of its cross platform appeal. However I am concerned because I've read mixed reviews on SO and other sites. The things that worry me are:
Subpar android support
Camera support not fully capable (e.g ios 4.1 HDR capability)
Camera support buggy
The nightmare scenario for me would be to invest time in titanium only to discover later on that its a major PITA and drop it and go "native"
Please share your thoughts and experiences.
I chose Titanium for a serious application, although one that does not use the camera. I think there are a variety of things that could play into your decision...
If your app intends to do "fancy" stuff with the camera, or some real heavy image processing and so on, you're likely better off going native. If on the other hand, you just want to have it take pictures, and then those will be used as-is, or sent to a server, or what not, then Titanium should work just fine. Titanium does have some processing and image manipulation things, but as others have said, if you really want to take advantage of the device's hardware, you probably want to go full native.
It should also be noted, and Appcelerator says this as well, that with a Titanium app, you won't just write a single app that works as-is on all devices. You will need to taylor the UI to each device (or class of device, i.e. iPhone, Android), because they have different UI's, and different standard UI flows and so on.
But, one of the potential advantages to Titanium is if you don't know Objective-C and/or Java, and you do know JavaScript (and in my case, I'm actually using Coffeescript :). Or, if you would enjoy your work much more writing JS than ObjC/Java. This was one of the main reasons for me. I have done some ObjC dev in the past, and don't even mind it, but this project I'm doing is on a very very aggressive schedule, and it was just going to be far more effective for me to use Titanium. I was able to get set up and build an app extremely quickly, and I am not spending any time having to become more deeply familiar with the programming language I'm using, memory management bits (you can't fully ignore this with Titanium, but essentially they're doing it for you). Based on the folks I've talked to, and how much time they spend with memory management, Interface Builder issues (this is mostly the ease of forgetting to setup connections or hook various things up, IB is actually a pretty great tool), and so on, I'm quite glad I'm using Titanium.
While I expect to do an Android version at some point, it's not a priority. But, I'm glad to know that a large chunk of my app code will be re-usable, tested, etc. and that I'll wind up mostly just building/revamping the UI for Android, not rewriting networking code, data management, and so on. Android support will be much better (supposedly) in Titanium 1.5, but you may want to wait for that release to evaluate Android if that's a priority.
Finally, Titanium does have a "module" system, that allows you to wrap native code, exposing it as a JavaScript interface in Titanium. We are about to leverage this to integrate a third party library, and at least for what we need, it looks very easy to use, and has given me a little more confidence that if some particular native feature we need access to comes up, that we'd have a decent chance of integrating that while still using Titanium, but I think it would depend on what the particular native functionality was.
Good luck and enjoy building a mobile app, it's pretty fun!
We have been using Titanium in one of our projects for around 2 months, and frankly speaking our experience with Titanium is too bad.
As per my opinion, below are some major drawbacks of Titanium:
1) First thing is you will not get debugging support at all (We can understand how debugging require in any of the project and in any of the technologies).
2) Titanium is NOT fully supporting all the features of Android/iPhone; beyond some level it will not give you support.
3) Comparing with Android/iPhone SDK, developers will get very less amount of help from the internet and API library (Titanium provides the API library help file).
These are the general issues that end developers face while dealing with Titanium and I suppose sometimes it will be tedious and frustrating work for them.
If the functionality of your application is somewhat like displaying data from the web (like many news, media type apps) then Titanium is the suitable option; otherwise not.
The Android support is not near as good as it is for the iPhone. If you were to just say iPhone I would say you would have luck using Titanium. However, I think trying to build one code base in Appcelerator and also use in your Android environment may not be the best experience.
That said, IMO doing Android / Java code is much easier than doing Objective C / iPhone work.
So worst case I would consider using Titanium for your iPhone version & do Android in Java.
You can give it a shot doing them both in Titanium, but worst case code the Java version.
I just hate objective C and the 'native' Apple development environment so much.
I would recommend against using a cross-platform toolkit when interacting with device hardware is one of the key requirements of your application. I haven't worked with Titanium before, but I find it hard to believe that they will give you the same level of hardware access that you get with native frameworks.
In particular, iOS 4.0 added a mess of new capabilities regarding the camera, including live video frame processing through AVFoundation, and I find it hard to believe that a third-party framework will keep up as these platforms advance. To be honest, it's pretty easy to write an application that interacts with the camera on the iPhone nowadays (count the number of them on the App Store as an indicator of this). I wrote a live camera frame processing application in about six hours the other day.
I can't speak for Android, but I imagine dealing with cameras is fairly trivial using the native APIs there as well.
You're also going to find performance testing and debugging your application to be far easier using the native tools than those supplied through a third party. In particular, Apple's Instruments is an extremely powerful, yet easy to work with, application for tracking down CPU and memory issues within your application.
There's also the community aspect. You'll find far, far more people working on Android and Cocoa Touch than on Titanium (just look at the numbers of questions in the various tags on Stack Overflow to see that). This means many more tutorials and a whole lot more sample code that you can use.
The time you'll spend getting your iPhone and Android build environments set up, and submitting to both stores, will be the same no matter if you go with a native environment or with Titanium.
In the end, even with learning both platforms, I think you'll come out ahead by avoiding a cross-platform solution. Trust me, I've tried to do cross-platform development before for other projects and ended up with lowest-common-denominator products that took much longer to write.
I've developed an Appcelerator-based camera application and was very pleased with it. I think some of the negative reviews come from the fact that it's a bit hard to get set up (more due to Apple's crazy developer registration process).
Once I got started, it was easy to do things like overlays on top of the camera screen. I was really expecting difficulty with that part, but it worked well.
I have spoken with the Appcelerator team in the past, and they are a great group to work with. I've seen them be responsive to other user issues, and I'd trust that if I ran across a real bug, they would address it quickly.
A little late, but my two cents...
I honestly believe you can very quickly prototype an application with Titanium Appcelerator and focus on the critical feature sets to determine if it is the appropriate tool for you.
All developers have there opinions and experience(s) which influence there comments; developers have different ways of learning and different levels of productivity... In the end, it comes down to how are you most productive with the tools available to you.
Since you are stating from the start that you want to deliver a solution an multiple platforms, I think it would be a poor decision on your part to not even spend a week or two investigating cross-platform frameworks and then making the decision based on your personal experience.
There is Titanium Appcelerator and there is also PhoneGap, where PhoneGap might help you is that there is the ability to extend/enhance the underlying framework through writing plugins (I wrote one for iphone ) and there is an android one on my blog also... this can fill missing gaps for you when you move across platforms.
Also since the UI in a phone gap solution is HTML5 Webkit based, it can give you a consistent look and feel across you devices if you like. Frameworks like jQTouch and JQuery Mobile are being used for UX with PhoneGap Application
I reviewed negative feedback for Titanium Appcelerator but I tottaly agree with Aaron Saunders that if you use PhongeGap Development is support HTML5 which can getting easy to make apps for iPhone, iPad and Android mobile.
Has anyone highlighted the cost off titanium.
I was contacted by them today and if you are more than a one man band you have to sign up for a partnership program else you are held liable for breech of contract if you release the app.
The partnership program is £5000 which is far to much for us as a start up company when it's our first application, we are currently looking for a different option now.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I'm a web developer and I'm getting envious of all the cool iPhone apps. I know nothing about C or what ever language they use to make iPhone apps. I really have no idea where to start. What do I need to do? Should I take a class, buy a book? I have a pretty good grasp on programing, I do tons of HTML, CSS and Javascript development and some PHP and Action Scripting. I'm not very good with Object Oriented Programing but I think I could pick it up if I used it more. I love video tutorials like lynda.com or net.tutsplus.com. I learn best buy jumping in and getting my hands dirty.
By far the best book I read on beginning iPhone development is called just that, Beginning iPhone Development. Very easy to read and takes you from a total beginner to reasonably competent. Check it out: http://apress.com/book/view/1430216263
I should also mention that every chapter has you jumping in and doing practical work. Most of the time you enter some code, get it running, and then go through it to understand it.
I haven't really looked into iPhone development at all. But as far as I know you can create a normal web app that can be accessed from the phone.
So depending on what you want to do, you could use your existing skills to make web apps specifically targeted at the iPhone.
Otherwise, if you want to develop an app, then Objective-C is the language the iPhone uses.
As far as I know you have to have to develop any apps on a Mac if you want them to go into the apple store. There are possibly a few other restrictions as well that you would have to look into if you want to publish the app that way.
You may start by some online videos as you love video tutorials, the Stanford course is one of the best.
Then you can pick up a book or two.
If you still feel comfortable after that, you may start a real project and ask questions on StackOverflow along the journey ;-)
Enjoy~
You sound just like me!
The first step is to know what iPhone apps are programmed in, which is Objective-C, an object-oriented version of C. Basically, Objective-C is how you write for the Cocoa API (which is the preferred API for all things OS X).
Personally, I say write really great web apps that have style/scripting for when the user is viewing from their iPhone. Here are some sites with that in mind:
iui - css for iPhones
iwebkit - general framework
PastryKit - js framework for iphones
Learning iPhone programming and Objective-C programming at the same time will be daunting. If you're serious about getting into this, I recommend you start by learning C on the command-line, then advance to Objective-C GUI apps on the desktop, then eventually move to the iPhone.
If you want to short-cut the process, there are plenty of join-the-dots tutorials online and a whole bunch of iPhone programming books targeted at different levels of experience, but you'll need to be pretty tenacious; the online stuff is of extremely variable quality and there will be a lot of cursing and hair-pulling. I have almost 20 years of C and C++ under my belt, but I still lost a lot of sleep getting up to speed.
Don't be discouraged, though; it is extremely gratifying to finally get something up on the app store and see people enjoying it.
If you really want to know how to make a good iPhone app, don't take shortcuts. Leave all of the intermediate products out and forget about just wrapping a website up in a UIWebView. Learning how to do it the right way will make you a better, more well-rounded programmer.
Since you don't know much C or Objective-C, I'd recommend reading Programming in Objective-C 2.0 by Stephen Kochan. It's a great book for going from no C experience to learning Objective-C. It also includes some iPhone-specific stuff.
Check out Jonathan Starks book on iphone apps. He shows how to use HTML, CSS, and Javascript to make iphone apps. You can distribute them from a server or use phonegap to convert them to native apps (legally!). This is probably the first direction to look into to leverage your existing skills.
http://building-iphone-apps.labs.oreilly.com/
Like so many has written already. Start by learning Objective C. Here is a great list of resources updated regularly. The comments are really helpful.
http://iphoneresources.aribraginsky.com/
The resources covers both Object-C and iPhone programming. Sections can be found various topics like game programming, twitter, etc.
If you are serious about this, your first step is to buy an Intel based Macintosh. They all come with Xcode (the developer tool) on a DVD.
Then you can seriously think about learning Objective-C and there are many good suggestions about that already here.
Stanford has their iPhone development courses on iTunesU but if you aren't good at Object Oriented programming then you are going to struggle with Obj-C.
Personally I would suggest learning Java to pick up the OO fundamentals first and then looking into Obj-C programming.
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.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
[2015 update: I think it's safe to say that Flash is rapidly dying. Don't go there. Gotta say though, during its brief moment to shine, Flex was actually a really lovely datavis technique.]
I'm interested in developing for the iPad and iPhone, but I'd prefer not to learn Apple's whole development stack (and good golly, I sure don't want to go back to manual memory management). Oh, sure, I could learn it, but I don't have that level of commitment to the environment at this point. I've got professional experience with Flex already, so I'm intrigued by Adobe's move to make Flash/Flex compile to the iPhone and iPad. My question is: how promising of a development path will Adobe's Slider be? Are we likely to see Slider publicly available in a reasonable timeframe (Adobe: "An early mobile branch of the Flex framework is expected to be available in 2010")? Are we likely to see reasonable performance? Are there development hurdles that haven't become clear yet? Heck, is it all just vaporware? There's pretty limited information available so far, as far as I've seen, but I'm interested in people's predictions, even if they're speculative.
Hopefully you'll see some info on Slider soon that will give you a better sense of the timeframe. Flex 4 will be released soon and once that happens you should start to hear more concrete info about Slider.
One thing to keep in mind is that Slider will be based on the Flex 4 architecture. To give you an idea of how that performs you can check out James Ward's blog post - http://www.jamesward.com/2010/02/21/flex-performance-on-mobile-devices/ - he's got a couple of videos that show a Flex 4 list running on a Nexus One.
This isn't iPad/iPhone, and Flex is NOT something Adobe recommends for mobile, but this basic example works pretty well. And it should give you an idea of how Slider might look/behave.
=Ryan
ryan#adobe.com
Interestingly, Apple's new developer agreement calls into question whether apps built with Flash/Flex will be allowed:
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).
Adobe's cross-compilation tech is not vaporware (for Flash, anyways-- haven't seen as much re: Flex). And they would be unlikely to invest so much in it if they thought it would get torpedoed on day one. That said, you must draw your own conclusions about your long-term reliance on it, and your interest in building on a non-native toolchain, both in terms of what you can get out of the environment, and the support channels you'll need to use (e.g. not Apple) when stuff doesn't work.
Some people seem to be successfully using Mono touch, which shares (some) similarities.
There are two issues with this:
Steve Jobs says he isn't going to support Flash on iPhone or iPad.
Adobe's next rev is going to allow you to develop in Flex and port to iPhone app format.
Do the math.
If you want to start iPhone, iPa or Mac OSX development, I'd suggest learning Objective-C. It'll probably take less time than waiting for (official) Flash support on those devices ...
Take it the other way around, would you use Objective-C to develop a Flash or a Flex app?
Flex can now compile iOS applications (and so run on the ipad and iphone)
http://gregsramblings.com/2011/06/20/finally-its-here-flex-on-ios-android-and-blackberry-playbook/
http://gregsramblings.com/2011/04/26/convincing-developers-that-adobe-flex-rocks-on-android-ios-and-playbook/
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
MonoTouch seems like a great platform for iPhone development, but I'm concerned about deploying it to the Apple Store. Are there any examples of applications built with it that are currently available on iTunes?
We're starting a new project for the iPhone, and keeping the entire stack in C# would be great, but we don't want to incur the risk of being turned down from the Apple store because of MonoTouch.
I've read about several games that currently use mono (not MonoTouch) for 3D graphics, but couldn't find anything about MonoTouch.
Tapping this out on my phone, so going to be a little terse - apologies for that.
Anyway:
- As said in a previous answer, there have been MonoTouch apps released to the App Store. Whether it's two or a bajillion doesn't matter so much. The difference between one and zero is infinite - the answer is unequivocally: Yes, Apple will approve MonoTouch apps.
- MonoTouch plays by Apple's rules. It spits out native bits. There's no interpretation of code going on, nor is there any JITting. Your MonoTouch app is a bundle like any other, and it contains a native binary like any other.
- MonoTouch apps are larger than they would be if they were written with Apple's stack. This is because your MonoTouch app relies on a subset of the Mono/.Net framework. In that respect, though, once you get down to what ships, there's nothing especially different about a MonoTouch app. I worked at a company where we built our apps (developed with Apple's stack) against our custom framework. It increased the size of our apps, but it also cut way down on production time (and that's always the trade-off, right?). Plus, the size of the app bundle just after compilation can be deceptive. Because bundles are zipped for the App Store, the size decreases dramatically - you can easily write a MonoTouch app that falls well within the acceptable size limit for apps delivered OTA (I bring this up because it's a question MT n0obs (rightly) tend to ask). So, Apple doesn't have any real reason to reject based on size.
- Whether it's MonoTouch or a custom in-house framework like the one I used to work on/with, the MonoTouch stuff, when shipped with your app, is just another framework that could've been written in Objective-C.
- If you're concerned about configuring your app for distribution using the entire MonoTouch stack and how that might affect your chances of approval, you can tell MonoDevelop (or the mtouch utility from the command-line) to output an Xcode project. You'll see that your code has been transformed - you'll be looking at native assembly (not some flavor of an IL). You can build and run your MonoTouch produced app from right within Xcode, by which time MonoTouch is basically out of the picture (except as a framework you're building against (like MapKit, for example)).
For some reason, all of this bothers a very small, but vocal, subset of iPhone devs who, for whatever reason, can't stand the idea of people they don't know using a different tool to build apps. But their hateage doesn't change the simple fact that Apple has accepted MonoTouch apps (and Unity apps long before that).
The biggest reason you're going to see for MT apps being rejected is that MT devs, in my experience (I've been talking to quite a few - after giving some talks, posting to forums, mailing lists, here...), is they they haven't yet learned how to develop an iPhone app. That's something iPhone devs must do regarldess of how they write their apps. MonoTouch isn't the obstacle - it's knowing, for example, that Apple wants your app to look a certain way and to work in a certain way - it should look and feel and behave like other (good) iPhone apps, and shouldn't be among the examples of attempts to write desktop apps for a phone (which is where your average dev makes his first mistake when transitioning to mobile development).
Ultimately, your tool of choice isn't going to matter as long as it creates bits that play by Apple's rules (like MonoTouch). The real obstacle is learning the iPhone Way of app design.
.Net application devs, whether on Windows, Windows Mobile, or wherever Mono (not MonoTouch) runs, are accustomed to developing apps according to their own tastes. That doesn't fly in the iPhone world.
You can safely go with MonoTouch. As has been shown, Apple will approve MT apps.
The thing you really need to do (again, regardless of which dev stack you choose) is read Apple's docs on iPhone app design and their guidelines. There's a huge crowd of devs out their attributing their app rejections to Apple being evil (or whatever - uninformed excuses, basically), when the truth is that their apps are garbage and it's clear the devs didn't play by the rules (or even bother to read the rules).
In the end, in many cases, you'll write far less code when using MonoTouch, and the cost for that is a larger app bundle (which, as I said, will come out very reasonably sized after it's been zipped for distribution).
That's not much of an issue. With 3g, users don't sweat downloading 2-3MB sized apps. If it's small enough to send OTA, everything's fine. And in cases where your app goes over the limit, it's likely embedded resources (media - images, videos, etc. - that's how bundles typically swell to wifi-only sizes), and that's something Objective-C devs have to deal with, too, so that's not a MonoTouch problem.
So, ignore the haters (who haven't even tried MonoTouch or bothered to learn how it works), and rest assured that, as long as your app conforms to Apple's guidelines, there's no reason for them to reject it. It doesn't mean your app is guaranteed acceptance as long as you design it correctly (plenty of apps get rejected for no apparent reason), but you can consider yourself, more or less, to be on equal footing with devs using Apple's tools.
Hope this helps :)
The MonoTouch community is maintaining a list of MonoTouch applications that are available today on the Apple Store and that have been written using MonoTouch.
The unity game developement platform is using the same mono touch code base for C# support (and have contributed to the project).