Live data from Hacker News

New iPhone Agreement Bans Flash-to-iPhone Compiler & Others

daringfireball.net

221–230 of 495 posts

Re: New iPhone Agreement Bans Flash-to-iPhone Compiler & Others

#221
post #113

Welcoming explanations for how this is a good thing for Apple's end users.

Because the apps will be running on controlled development libraries that might be able to.... perhaps multitask in OS 4.0, remember guys this is a phone we are talking about here, not a games console, security is paramount, and apple is just trying to put the the genie back into the bottle before a mass of insecure apps are elevated up the permission chain in 4.0 to be able to operate on a par with apple authored ap…

using a different language doesn't affect security, the executable is still within the same sandbox. please read up on the plethora of projects allowing other languages to work with Cocoa, including desktop OSX, including Apple-funded projects like RubyCocoa.

Re: New iPhone Agreement Bans Flash-to-iPhone Compiler & Others

#222

Earlier quoted context omitted.

Sure, 'multiplatform compiling/targeting' is one thing. But banning non-approved languages is silly. Even apple is funding projects like RubyCocoa and bringing Python compatability to the Cocoa API. If somebody wants to write an app using CocoaTouch but finds Ruby, Python, Lua, or Mono to be a better fit for the project or their own capabilities than Obj-C, why stop them from doing so? If the apps still have to inter…

Think OS/4, think opening up multitasking to 3rd party apps, perhaps thats why they are being so anal about how apps should be written, if they are planning to make changes to the low-level libraries to support 3rd party app multitasking then they are going to want to make sure that 3rd party apps are linked against them.

This argument makes no sense. These third party tools are using only the publicly documented Apple APIs. They are simple doing so through an intermediary layer. It has nothing to do with using private or low level libraries.

Re: New iPhone Agreement Bans Flash-to-iPhone Compiler & Others

#223
post #75
post #15

Earlier quoted context omitted.

I have been a very loyal mac user for years and love it, but I'm seriously considering going back to Linux. I am not a free software "zealot" and don't mind some closed-ness, but this is getting absolutely insane. Enforcing which LANGUAGES can be used on a platform?!? Insane! Edit: I've been looking at these guys: http://www.system76.com/ (I don't work with or have any vested interest in them, but they look cool.)

Boycotting the Mac platform (which is pretty much free of any such absurdity) doesn't make a lot of sense to me. That's where Apple is doing things right . You should of course, shun iPhone OS devices if you feel this way. The system76 laptops are probably generic machines from Clevo, Sager or some such with a custom badge. Alienware used to do the same thing.

Boycotting the Mac platform (which is pretty much free of any such absurdity)

For now.

That's the thing about Apple's capricious, passive-aggressive contract language... you have no idea, and no way to even guess, if your business model will be the next one they target for termination.

Re: New iPhone Agreement Bans Flash-to-iPhone Compiler & Others

#224
post #186

Earlier quoted context omitted.

If the cross-platform experience is subpar, Apple should just let these apps fail in the market.

Apple don't believe in a free market / free competition. If they did, then they wouldn't have an App Store.

I don't think there's any government intervention forcing people to work on (or not work on) app store apps.

I think apple is doing well in the (presumably free, it's way more open than other places) market, because they are very good at negotiating their property rights.

I guess it's just fashionable to imply the "bad guys" are "communists"

Do you mean the FCC approval process for new cell phones is a massive barrier to entry? I'm sure it's not free, but i can't imagine they'd want more that a few dozen phones and $100k of studies. maybe a half a million?

Re: New iPhone Agreement Bans Flash-to-iPhone Compiler & Others

#225
post #12

Say hello to the new boss, same as the old boss. The corporate pissing matches have started in earnest... When Alan Kay said Apple would take over the world with an iPad, I don't think he realized that eToys or anything like eToys would never be allowed to run on the device and that a majority of the apps will probably have commercial spots embedded within them. Actually it reminds me of "educational" tv all over aga…

> Say hello to the new boss, same as the old boss

Who do you mean by this? Microsoft doesn't make sense in this context.

Re: New iPhone Agreement Bans Flash-to-iPhone Compiler & Others

#226

I can think of only two (tenuously) justifiable reasons for this. 1 - Perhaps, during the beta, they want code written in C (and derivatives) to aid in debugging framework bugs. Rather than "My App doesn't WORK!!!!! (Using MonoTouch Vxxyy)", they can get a repro using a stack they know and control top to bottom. In this case, I can see it as justified. 2 - If it's specifically to target cross-compilers as a business…

please try to distinguish 'cross platform compilers' from using alternate languages to write for Cocoa APIs. it doesn't matter if you're using C# or Ruby, your program is still structured around all the native APIs necessary to function. Unless somebody reverse engineers a similar platform with identical APIs (and thus, likely built on Obj-C as well) you aren't getting around targetting CocoaTouch specifically. And there isn't anything stopping anybody from releasing cross-platform-compiler 'meta platforms' which DO use Obj-C and thus qualify under Apple's new rules.

Re: New iPhone Agreement Bans Flash-to-iPhone Compiler & Others

#227
post #54

This is unsavory in the extreme. I had been writing an iPhone app in Haskell, and now I have to can it? What the fuck? Fuck you, Apple! Blowhards. Hope you guys enjoy the mass exodus of decent developers from your dumbass platform with kiddie languages.

Have you tried writing your Haskell-based app for Android? Or perhaps Windows Mobile? or Palm?

Re: New iPhone Agreement Bans Flash-to-iPhone Compiler & Others

#228

Getting 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.

Apple isn't interested in proving a point about market viability, they just don't want that on their platform.

Re: New iPhone Agreement Bans Flash-to-iPhone Compiler & Others

#229
post #54

This is unsavory in the extreme. I had been writing an iPhone app in Haskell, and now I have to can it? What the fuck? Fuck you, Apple! Blowhards. Hope you guys enjoy the mass exodus of decent developers from your dumbass platform with kiddie languages.

"your dumbass platform with kiddie languages."

That's ironic.

Objective-C, C, and C++ are kiddie languages?

I seriously doubt that there will be any sort of exodus away from iPhone development because of this. Apple provides some awesome development tools, and they want developers to use them because they improve the quality of the applications that people write.

Re: New iPhone Agreement Bans Flash-to-iPhone Compiler & Others

#230

Isn't MacRuby sponsored by Apple? There's been discussion re: writing iPhone apps with MacRuby, AOT compilation. I wonder how that project will be affected? http://lists.macosforge.org/pipermail/macruby-devel/2010-Jan...

It's not MacRuby, it's RubyCocoa, but yes, they have their own project using a language not included in this list. No, I'm not expecting consistency here against their own "baby", but what kind of environment does this set up? Would you even want to use RubyCocoa in this environment, much less a 3rd party language bridge to Cocoa (which is 100% targetting Apple's platform and APIs).
Post reply on HN