Related
I know that you need a Mac and Xcode and the SDK. But is it possible to develop apps for jaibroken devices and/or regular devices using Windows/Linux platforms ?
Edit
Also, what's the lowdown on the Airplay SDK ? Heard that it's pretty good but doesnt offer the same performance as an app developed through Xcode.
Found this PDF Document, for what it's
Actually you can, and that's what programming is all about. If you're a tough programmer you can do lots of cross platform and cross hardware stuff. Don't forget that no matter how cool Steeve Jobs is (or pretends to be) for Apple and maybe even non-Apple consumers they care about their profit and would never declare officially that building apps for iPhone and other iOS devices is possible on PC too. This way they make you get a Mac. They've been very successful in making people believe that building apps for iPhone is not possible otherwise.
There's a toolchain for Linux platforms, but it doesn't have Interface Builder or other niceties. Here's an example application that uses it.
You may be looking for theos. Have a look at this thread.
Of course, you will have to have your toolchain installed, which shouldn't be that hard. There are a lot of projects which involve having a Linux iOS toolchain. Windows is another story, though :P (not saying it's impossible!).
Short answer is no - fundamentally iPhone OS uses Cocoa, which is a closed framework only distributed with XCode. Some people have thought about reverse engineering (like Wine) but I don't think anybody has really been successful thus far, let alone use Cocoa as a development environment.
You might be able to create some debian packages (dpkg) that can be run in the background or via the mobile terminal. This is kind of limiting though, because you don't have access to GUI and your app won't be very intuitive.
There seems to be a development platform for porting Blender game logic into a full-fledged iphone game. Maybe you could avoid Xcode this way, but I doubt it.
http://sio2interactive.com/
You could run OSX within Virtualbox/VMWare Player but that's not allowed by Apple.
Don't listen to other people who insist that you HAVE to get a Mac. You just need to download a copy of cracked VMWare with pre-installed Mac from http://thepiratebay.org/. You also need to download a copy of cracked VMWare player from the same site. Then download Xcode inside the Mac. No need to pay for anything. I've been using it and working great.
Short answer -- YES.
Although i'm not entirely sure what you mean by "ONLY" for jailbroken devices, but if you have any experience at all with flash scripts or action scripts then check out Adobe Flash Professional CS5.5. It's a program that lets you design and write your own apps for ipod/iphone/ipad.
http://www.adobe.com/products/flash.html
I've used it for years and find it perfect.
I have developed an app for the Android and it's working well, finally, and thanks to all the help from StackOverflow!!
Now I am being asked to make it work on the iPhone. I looked at iPhone a while ago but not recently.
What does everyone think? Should I take the time to learn Objective C and iPhone and port the app or forget it?
Are there any books that cross-reference functions so that you can look up how to do something in iPhone that you already have on Android?
From my experience in school, if you have already been able to create a working smartphone app in at least one mobile OS such as android, it wont take long before you can understand objective C and cocoa framework stuff. The only problem with that is you may probably need an apple developer license to use XCode.
So, I would say go for it since you also get paid, and also here is a link to iphone development guide for android developers : http://integratingstuff.com/2011/02/27/starting-iphone-development-as-an-android-developer/
Probably, it's better to get a partner who develop to iOS than doing it yourself.
Focus on a platform and let your products run to all users.
Unless you are using a framework that supports both iOS and Android (something like the Corona SDK) you won't have much actual code that will transfer over. Ideas, algorithms, logic, graphics, designs, etc will all transfer over just fine. Those are the hardest parts (IMO) of software dev.
Objective C (the language iOS apps are written in) is not that hard of a language to learn if you already know C-based languages (like Java). There are a few concepts that are different, but for the most part, it's not that bad. The biggest challenge for developing on iOS is buying a Mac. You can program for Android on Windows or Linux boxes, but iOS apps can only be developed on an Apple. Unless there is something that has happened in the Hacintosh arena that allows for iOS development on other platforms, you're stuck buying new hardware. BUT if you already have a Mac, download XCode and go to town!
Like Haphazard said, if there is enough money in it to make it worth your time, do it.
If you are getting paid, go for it! (Also, it could be a great learning experience.)
When I had to make the same decision, I considered the following criteria:
how much money is in the app on the other platform ?
how many times will this happen in the future, or is this going to be the only app? (how big is the benefit of learning the other platform for the future)
how much insider know-how is in the app that one is willing to reveal to another programmer porting this app (in my case I do mostly device handling apps, which is not really all that common)
what is the opportunity cost of spending time on porting an app instead of developing another profitable on the initial platform
If you have any possibility, you may look into similar apps and see how they are doing on the two platforms...
Good luck, whatever you are going to do...
I just learned about this and have not tested it yet, but one thing that you could do depending on the app you have you could take a look at PhoneGap. It looks pretty promising, though it may not work for your case with your initial application already made. But in the future this could help.
Unfortunately you will either have to re-write the app from scratch for iOS, or hand over the job to an experienced iOS developer. You can fairly easily port over the logic and computations in your app from Java to Objective C, but the user interface is the area where you cannot really re-use anything (except maybe icons), and the user interface tends to be a large portion of most apps.
As an Android developer who has ported several of my apps to iOS, I can say that this transition is a hard one. Firstly, you need to buy an iPhone and a Mac (if you don't already have these), since you cannot develop apps for iOS without the Apple hardware. Secondly, you need to learn how to use XCode and Objective C or Swift. And thirdly, since XCode ONLY allows creating the user interface graphically (as opposed to Android which lets you hand-edit the XML), there are many hidden things which can cause you to come unstuck. (UPDATE: Using the new SwiftUI approach to user interface design really helps with this last point, and in my opinion makes the transition from Android to iOS easier).
Finally the Apple and XCode environments seem rather alien to someone who is used to Windows and Android Studio. There are things like the Home and End keys having completely different behaviors to Windows which is frustrating. Also you have to use a combination of key shortcuts and mouse movements to hook up user interface elements to your code. Also, there are big annoyances such as the pop-up keyboard on iOS not pushing the content out of the way automatically like it does with Android. This is probably because Android is an OS designed for multiple screen sizes, whereas iOS is design for a limited number of screen configurations, but it makes iOS feel inferior and harder to work with from a developers point of view. (UPDATE: Using a ScrollView in SwiftUI solves the keyboard obscuring problem).
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.
I am interested in writing games for the iPhone and the Web. Ideally, there would be one language that I could write my games in and it would work on both platforms. I know this is not the case, so what is the best way to leverage code between iPhone apps (Objective-C/C++) and Flash SWFs (ActionScript)?
This maybe of some help
It uses the NME library which will allows code to mostly be written to the Flash 9 API and create the C++ for XCode to compile and run on the iPhone and Touch. This creates a path to port Flash games to iPhone/Touch.
Unfortunately, Flash and Objective-C are very, very different - and it's unlikely that a Flash player will be available for the iPhone in the near future. The native input methods used in Flash games - the keyboard and mouse - don't lend themselves well to the iPhone. While Apple could make Flash run on the iPhone, most Flash games would be totally unplayable (or feel very unnatural. They'd have to overlay a keyboard probably?). With the success of the App Store and native iPhone games, I think it's very unlikely you'll see Flash support anytime soon.
You might want to consider using a game development tool like Unity instead of Flash in the future. Unity allows you to create both 2D and 3D games, and you can program them in various .NET scripting languages. Once you've created the game, you can cross-compile it for web (their own plugin, not Flash), iPhone, or the desktop.
I know that doesn't help much since you have an existing codebase, but it might be something to consider for the future!
My company is developing a toolchain that allows compiling ActionScript3 to native code for mobile devices.
It now supports Windows Mobile and Symbian, and iPhone supported will be released in a couple of weeks.
Check it out at: http://developer.openplug.com/
BR
Guilhem
Adobe Alchemy looks promising. It is not released yet, but from their website:
Alchemy is a research project that allows users to compile C and C++ code that is targeted to run on the open source ActionScript Virtual Machine (AVM2).
This would allow iPhone apps and Web apps to share non OS-dependent C/C++ code, which is a very exciting prospect.
One option would be building everything in unity. The engine facilitates building the same game project to any of the following platforms:
Webplayer
OS X
Windows
iPhone
Wii
Actually, the iPhone supports Flash technically (see Developer creates Flash for iPhone and Flash Installer Update #2). It is just Apple's crippleware restrictions that prevent installation.
Other than that, there's really not much you can do. Flash/ActionScript and Objective-C are radically different. You can have a central server store data, but that doesn't solve the duplicated logic.
If you're already willing to use ActionScript you could go all the way over to the dark side and switch to Javascript. That's the only common language supported by your clients (web and iPhone).
How comfortable you are with either development environment certainly plays a role here. If you are a die-hard Objective C and a super star Actionscript programmer then doing both shouldn't be much of a problem. It will be lots of work of course, but not a problem.
However, if you are neither or only skilled at Actionscript then I suggest you focus on Flash/Actionscript for the time being. Eventually Flash will be available on the iPhone anyway. When that happens you can already have a number of apps ready to be quickly ported to iPhone. Also keep in mind. There are more portable devices out there than just iPhone. Getting your apps running on other devices might be worth it in the mean time.
Just keep in mind when you're developing your apps now that at one point you also want to run these apps on the iPhone. So make 'm in such a way that they can be controlled with an iPhone as well.
Updating this old QA with new information. The recently released monkey development framework deploys to both iOS and Flash: http://www.monkeycoder.co.nz/
It's so new that I wouldn't necessarily recommend it, but it has a great pedigree: the creator made Blitz3D and BlitzMax before, and those were great game development tools.
That said, I would strongly recommend a combo like Corona for iOS and Flash for web, so that you're using optimal tools for each platform.
I know there is a requirement in their EULA, but I heard about people getting their apps developed on Windows into the app store.
How can Apple find out, or do they even know?
They don't, so if you get a native compiler and toolset up and running on Windows, more power to you.
But realize that:
You will not be able to use a language that compiles to bytecode (that's Java, C# and the .Net languages, Perl/Python/Ruby, etc.). Apple will most likely not allow any sort of interpreter through the App Store.
Chances are your tools will not contain an Interface Builder equivalent or an iPhone Simulator equivalent. You're going to be writing a lot of code and spending a lot more time testing.
You won't have local documentation. You'll either have to use Apple's website or rely on third-party documentation which may mix App Store-allowed and -forbidden methods without indicating which are which.
You won't have Xcode's editor, which is highly specialized for Objective-C. You'll have to type a lot more.
You won't be able to get help as easily since you're not using the same tools as others.
You will never know when a bug is in your code, your tools, or your platform. People using the official SDK can file bug reports on the tools just as easily as the platform.
Your tech support incidents are worthless, because you're violating your contracts.
If Apple ever does find out, you're likely to be kicked out of the App Store and all your work will be for nothing. Unless you're an idiot, this thought will worry you.
If you're a hobbyist, these may be acceptable to avoid paying $400 for a used Mac mini, but if you're not a hobbyist...this is no way to run a business. Pick up a used Mac and think of all the money you're not spending on a factory, a store, offices, inventory, or employees during your setup time.
There is no sdk available for Windows. XCode only works on Mac OSX, how would one compile, test, and run the app if not on Mac OS X?
I dont think they know. There's no official SDK for the PPC architecture, but some simple installer hacking yields a working binary for my Powerbook. Similarly, if you get your code working on Windows, more power to you...