Earlier quoted context omitted.
Apple might say the rationale is to allow easier inspection of apps for policy compliance. (Even though other languages compiled-to-approved-languages will be the same for automated analysis, it's more likely the code will be inscrutable to human reviewers.)
You don't submit your source code to Apple. Why should this matter?
New iPhone Agreement Bans Flash-to-iPhone Compiler & Others
131–140 of 495 posts
Re: New iPhone Agreement Bans Flash-to-iPhone Compiler & Others
#1321. Apple takes iPhone stability and security Very Seriously. 2. ??? 3. Therefore, if you write native iPhone apps, you must use C derivatives that expose raw pointers and direct memory access.
Re: New iPhone Agreement Bans Flash-to-iPhone Compiler & Others
#133Who's going to know? My C happens to look exactly like what Chicken Scheme generates!
Re: New iPhone Agreement Bans Flash-to-iPhone Compiler & Others
#134Re: New iPhone Agreement Bans Flash-to-iPhone Compiler & Others
#135Earlier quoted context omitted.
GHC has a C backend. Just claim that you wrote that code yourself. Problem solved.
I don't want to invest months of my life, only to be told, "sorry, if you can't prove it's C, your app is rejected. Bye."
Re: New iPhone Agreement Bans Flash-to-iPhone Compiler & Others
#136If you think of the iPhone as a PC-like platform, yes, it's worth being crazy. But I think of mine as more like a game console. That helps me minimize my own feather ruffling, even when Apple does snarky things to me during the review process.
Re: New iPhone Agreement Bans Flash-to-iPhone Compiler & Others
#137Getting away from the frenzied rhetoric, my opinion is that what Apple really wants to prevent is people releasing multi-platform compilers. So taking Flash as just one example, if I can build one app and the compiler can make me an iPhone executable, an Android executable, and so forth, Apple don't want that. In my experience so far with such "cross platform compatibility layers," they always produce results that wa…
If the cross-platform experience is subpar, Apple should just let these apps fail in the market.
Perhaps, like Nintendo, they learned the lessons from the collapse of the home video game market in 1983. When Nintendo was contemplating developing the NES, they took a deep look at what had caused the collapse. What they concluded was that the main cause of death was the market being flooded with too many crappy games.
Originally, if you wanted to write, say, an Intellivision game, you went and got a job with either Mattel or APh Technological Consulting (the company that did the hardware design, system software, and many of the early games for Mattel). If you wanted to do an Atari game, you went and got a job with Atari.
The games at this time were all pretty good. A consumer could go out, buy a game based just on the information printed on the box, and go home and be pretty sure they'd have a good experience.
As time went on, a few more companies joined the party. Activision and Imagic, for instance. These companies were started by people who had worked for Mattel or Atari or their contractors like APh, and generally produced quality games.
A consumer still could be confident that plunking down $40 or whatever for a new game, based just on the box description, would be a good move.
More time passed, and companies that had little or no connection to Atari and Mattel jumped in, using information gleaned by reverse engineering the consoles and system software. The information was not always complete, and they didn't know all the tricks and techniques we authorized developers knew to squeeze greatness out of the hardware. They produced a lot of crap games.
Consumers now found that spending $40 on a game was a big gamble. They had to work to get good games--be aware of brands, read reviews. They stopped buying--all games, not just the bad games.
Nintendo's conclusion was that their new console must be locked down. Only developers that Nintendo approved would be allowed to produce cartridges. This way, they could ensure that quality remained high, and get the now shy consumers to come back and give games another change.
It clearly worked--and consoles have been locked down ever since, and the console game market is huge.
Re: New iPhone Agreement Bans Flash-to-iPhone Compiler & Others
#138Wow. Just wow. I was planning on building an app in Titanium. I guess I'll wait and see how this shakes out first. btw, at the time of writing this comment Titanium's developer center is hosed. Maybe it became self aware at the same time and commited suicide. http://developer.appcelerator.com/
Re: New iPhone Agreement Bans Flash-to-iPhone Compiler & Others
#139I don't like this at all. Maybe they only meant to hit Flash, and maybe not, but as written this is in direct opposition to one of the most important principles of software development. Apple themselves must have benefited countless times from writing software in layers. But no layer above their layers is permitted? I wonder if the open source world can successfully fight back, by making compilers that generate code…
I think the answer is definitely yes. Apple's software engineering is not that great. There is always some hole in Safari that allows root access to the entire device. They can't get atomic syscalls working in OS X. Does anyone really think they can recruit and afford people that can tell computer-generated software from hand-written software?
My guess is that this is a scare tactic to keep anyone thinking of supporting two platforms at once to "not want to risk it" and go for the iPhone instead. More users, only so many hours that the developer can be awake, safer to just go with the iPhone. (Of course, you are already risking it anyway; use the wrong multi-touch gesture -- app denied. Use a Google service -- denied. Do something useful that Apple wishes they thought of first -- denied. And people wonder why there are so many fart apps...)
My next guess is that this tactic will be successful. People seem to adore doing whatever Apple tells them to do. It frightens me.
What I've learned from iPhone vs. Android (among other things) is that people will pick pretty and mean over average and nice.
Re: New iPhone Agreement Bans Flash-to-iPhone Compiler & Others
#140> Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine Controlling programmers like this seems positively insane, doesn't it? Does this mean that games can't do scripting in something like Lua either, under the letter of Apple's law?
Lua is definitely out, and has been out for longer: Apple explicitly prohibits embedding interpreters, like the Lua interpreter, in your apps.