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).
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.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'd like to start developing for iPhone or Android in my spare time, as a chance to learn something new but also hoping make some extra income.
I'm not sure which is the best development for me to start developing on. I own an iPhone, but I don't have a Mac (which I would need to use the SDK), plus with the iPhone I believe there's an annual charge to develop for it.
As far as I understand Android, the SDK is free and can be used on Windows.
Professionally I develop using .net and C#, which sounds more similar to the Java based Android enviroment.
Another negative I perceive against iPhone is it has a much more crowded App Store, I would think apps get better exposure on Android?
Both can be good/bad for various reasons.
iPhone - good
Great SDK & get to use Xcode which rocks
Well documented online (many tutorials)
Large deployed base of devices
Well established app store
Get to learn Objective (I find it a fun language)
Most people tend to upgrade their iPhone OS so you can get away with only developing for the latest and greatest
iPhone - bad
Crowded app store, very hard to break through (the "gold mine" is a myth)
App Store apps need to be approved by Apple, with some often rejected for dubious reasons
Have to buy a Mac (not necessarily a bad thing)
Have to learn Objective C (can be a hassle)
Have to pay $99/year to publish apps
Can only multitask on iPhone 4.0+. Hardware restrictions will mean many devices will not be able to use this however
Android - good
No restrictions on apps that you can develop/publish
Wide deployment of devices and growing - set to overtake iPhone soon
Can multitask on Android
Get to code in Java which is widely known
Some of the SDK tools integration with Eclipse is nice (although still needs a bit more work)
Only have to pay $25 to publish apps (one off fee)
Can develop on any platform (Mac/Windows/Linux)
Great Android devices coming out this year - platform could really take off.
Nice XML way of laying out views. While not as flash-looking as the iPhone Interface Builder, it is very powerful.
Get to work in Eclipse (which some people think rocks)
Android - bad
Have to support wide variety of screen sizes and devices
Many people still using old versions of Android OS (1.5) so you'll probably have to support those if you want to reach that market
SDK is not as polished as iPhone SDK
Android Market is not as popular as iPhone App Store - hit apps will not make as much $$$
All in all, starting with whichever is fine in my opinion, especially as now Android is gaining ground. Given your background I'd say you should go for Android.
In my honest opinion - I see the recent changes in iPhone SDK a kick in the teeth. I'm an Adobe person and you would assume, an infinite number of developers begin building applications in CS5 would be great for you App Store? Apparently Apple do not agree.
However - if your looking for exposure, getting an App into the App Store will yield more results if you build a quality app. As the Android store hasn't got a footing yet (if they'll ever be one), all marketing is on your own head.
I recently defunct Apple as they force us developers to 'be them' and I don't agree with their ethos.
That said, having programmed for both, The Android is slightly tricker to get installed and took a very long time to sort itself out. Although the instructions are very good and the examples are well defined.
If you've got a mac, installing the iPhone SDK is a sinch and you ready to build apps. It does cost £50 for the developer connection and yes android is free. [Correction - this may cost a one of fee of $25]
If you are building an iPhone app thats heading for the wild, you will need the connection (this can take up to 3 weeks in my experience) so you can test it on your iPhone.
And you'll definitely need to purchase a Mac.
--
With Android, its java, and with the newest rendition, a very good API to work with. As an additional bonus its build upon Eclipse, so it'll take you seconds to understand whats going on.
--
As a final thought - being an Actionscript/JS developer, the transition to Java was a logical and simple step and (please don't shoot me if you don't agree) Objective C is a train wreck of two different language styles. I found it very very difficult.
but don't just take my word for it, definitely try them both, as I see Android emerging market just an ice berg right now, but Apples is established.
Two disadvantages of iPhone/iPad apps ecosystem are:
Apple test & accept apps before puts them into AppStore (this take time and acceptance depends on Apple current policy) -- Google seem not to care about that so much.
AppStore it's the only official place for iPhone apps -- on Android you can install apps from unsafe source (i.e. website or email attachment) -- so you can provide and charge for app in various ways.
You say you want to (a) learn something new and (b) make some extra income.
As far as (a) goes, your barriers to entry with Android are probably lower. You can develop on Windows, Linux, or Mac; the sdk is free, and there are no charges. Android development is usually done in Java, which is not that different to the c# you already know. So, I'd say get Reto Maier's book and give Android a try. At some point you'll need an Android phone, but you can get some way using the emulator. You won't have to buy a mac or pay for a developer licence.
Once you're familiar with developing for a mobile platform you'll have a better idea of what it takes to build apps that other people will want to use, and maybe even pay for. At that point you can evaluate the platforms from the point-of-view of (b) and decide which one to pursue. If you end-up buying a mac and paying for a development licence then at least you'll be making an informed decision. But get some experience first.
Like you, I'm a c# dev. I've done some Android development for my own amusement, and (for what its worth) my personal opinion is that its a superior platform in comparison to the iphone because it is more open (technologically and commercially). I believe Android will fairly soon either achieve partity with, or even overtake, the iphone.
Try Android, get some mobile experience, then decide.
MonoDroid for Android is in beta, which means you'll be able to write Android apps with C#. You can sign up for the beta here.
iPhones are getting more and more restrictive. Android is opening up. Android is also shipping more phones than iPhone. You decide.
take a look at this book , it's a good reference to decide the 3th way... HTML, javascript & CSS for iPhone and Android at same time, based on webkit, using jQTouch and
PhoneGap . You can see on the first chapter the pros and cons.
I would suggest getting your hands on the latest iPhone SDK and a Mac from a friend before taking the plunge unless the $600 minimum investment for a macmini(what I did in my case) doesn't bother you.
You could try installing GNUstep for Windows and messing with Objective-C without buying a Mac to check out the language but it's not the same without XCode and Interface Builder,SDK,etc.
The reason I say this is because I'm currently taking an iPhone class and just learning Objective-C is a lot larger learning curve than I thought it would be and eating up a lot more of my time than I cared for.
Unlike C# or Java you have to manually keep track of memory management which is really annoying and a hassle not to mention Cocoa Touch, which is sort of like .Net or Java classes for Objective-C; another big learning curve! Bottom line neglecting the fact that it is a mix of SmallTalk and C and looks horrible if you can get over that it is still hard and easy to crash your program.
Forget to hook up your outlooks correctly in Inteface Builder?
CRASH!
Forget to use an # for an NSSTring due to the loose type checking?
CRASH!
I'm just saying that you'd probably be more productive and actually get applications completed in your spare time going the Android more familiar Java language route vs the Apple route. Also, I'm not sure how big Android is on the whole MVC concept, but it's everywhere in the iPhone SDK since Cocoa uses the Model-View-Controller (MVC) design pattern throughout.
On the other hand, if you like a challenge or learning the Apple route is the way to go and if you are good you app will sell and you will make money. Like I said there is a ton to learn with the iPhone before you can even start thinking of selling the next killer app LOL.
p.s. Oh and unless you want to test something on actual hardware that doesn't work in the iPhone/iPad simulator or actually upload an app to the store you don't need to pay the $99 fee to develop.
If you're a C# developer, and you're looking to begin iOS development, then you owe it to yourself to read Josh Smith's iOS Programming for .NET Developers.
It's exactly what you're looking for.
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 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.